1. 管理者ガイド
  2. 管理手順
  3. データ破損からのリカバリ

データ破損からのリカバリ

Oracle NoSQL Databaseでは、データベース・ストア内のデータ破損を自動的に検出できます。データ破損を検出すると、Oracle NoSQL Databaseは、関連する管理またはレプリケーション・ノードを自動的に停止します。その後、ノードをオンラインに戻す前に手動による管理アクションが必要になります。

データ破損の検出

データ破損を検出すると、Oracle NoSQL Databaseの管理またはレプリケーション・ノード・プロセスは終了します。これは、ディスク障害、または同様の物理メディアやI/Oサブシステムの問題が原因で発生したデータ破損を検出するバックグラウンド・タスクによるものです。通常、破損が検出されるのは、管理またはレプリケーション・ノードのデータベース環境に含まれているいずれかのデータ(*.jdb)ファイルのログ・エントリにチェックサム・エラーがあるためです。データ破損エラーによって、次のような出力がデバッグ・ログに生成されます。 

2016-10-25 16:59:52.265 UTC SEVERE [rg1-rn1] Process exiting
com.sleepycat.je.EnvironmentFailureException: (JE 7.3.2)
rg1-rn1(-1):kvroot/mystore/sn1/rg1-rn1/env 
com.sleepycat.je.log.ChecksumException:
Invalid log entry type: 102 lsn=0x0/0x0 bufPosition=5 
bufRemaining=4091 LOG_CHECKSUM:
Checksum invalid on read, log is likely invalid. Environment is 
invalid and must be closed
...
2016-10-25 16:59:52.270 UTC SEVERE [rg1-rn1] Exception creating 
service rg1-rn1:
(JE 7.3.2) rg1-rn1(-1):kvroot/mystore/sn1/rg1-rn1/env 
com.sleepycat.je.log.ChecksumException:
Invalid log entry type: 102 lsn=0x0/0x0 bufPosition=5 
bufRemaining=4091 LOG_CHECKSUM:
Checksum invalid on read, log is likely invalid. Environment is 
invalid and must be closed. (12.1.4.3.0): oracle.kv.FaultException: 
(JE 7.3.2) rg1-rn1(-1):kvroot/mystore/sn1/rg1-rn1/env 
com.sleepycat.je.log.ChecksumException: Invalid log entry type: 102 
lsn=0x0/0x0 bufPosition=5 bufRemaining=4091 LOG_CHECKSUM: Checksum 
invalid on read, log is likely invalid. Environment is invalid and 
must be closed. (12.1.4.3.0)
Fault class name: com.sleepycat.je.EnvironmentFailureException
...  
2016-10-25 16:59:52.272 UTC INFO [rg1-rn1] Service status changed 
from STARTING to ERROR_NO_RESTART

EnvironmentFailureExceptionによって、プロセスが終了します。この例外の原因はログの破損であるため、サービスのステータスはERROR_NO_RESTARTに設定され、サービスは自動的に再起動しないことを意味します。

データ破損のリカバリ手順

データ破損が原因で管理またはレプリケーション・ノードが停止した場合、ノードを再起動するには、手動による管理介入が必要です。

  1. オプション: 破損した環境データ・ファイルをアーカイブします。

    障害の根本原因の特定に役立つよう、破損した環境をOracleサポートに送信する場合は、破損した環境データ・ファイルをアーカイブします。これらは通常、次の場所にあります。 

    <KVROOT>/<STORE_NAME>/<SNx>/<Adminx>/"

    または 

    <KVROOT>/<STORE_NAME>/<SNx>/<rgx-rnx>"

    ただし、plan change-storagedir CLIコマンドを使用してレプリケーション・ノードのストレージ・ディレクトリを変更した場合は、そのコマンドに指定した場所に環境があります。

    show topology CLIコマンドを使用すると、ストアのトポロジを表示できます。この情報の一部として、各レプリケーション・ノードのストレージ・ディレクトリが識別されます。

  2. データの破損していないバージョンが使用可能であることを確認します。

    破損した環境に関連付けられているファイルを削除する前に、別のノード上で、または以前に保存したスナップショットからデータの別のコピーが使用可能であることを確認してください。レプリケーション・ノードの場合、データがストア内の他の場所に存在するためには、1より大きいレプリケーション係数を使用している必要があるとともに、正しく動作しているレプリケーション・ノードがストア内にあることも必要です。RF=1を使用している場合、続行するには、以前に保存したスナップショットが必要です。

    管理ノードに問題がある場合は、使用可能な別の管理がストア内にあり、正しく動作していることが必要です。

    pingまたはverify configurationコマンドを使用して、使用可能なノードが正しく実行されていて正常であるかどうかをチェックします。

  3. 破損した環境に存在するすべてのデータ・ファイルを削除します。

    破損した環境に関連付けられているデータ・ファイルが他の場所に保存されており、データの別のコピーが使用可能であることを確認したら、環境ディレクトリ内のすべてのデータ・ファイルを削除します。破損した環境エラーが原因で障害が発生した管理またはレプリケーション・ノードに関連付けられているファイルのみを削除してください。 

    # ls <KVROOT>/mystore/sn1/rg1-rn1/env
00000000.jdb  00000001.jdb  00000002.jdb  je.config.csv  
je.info.0 je.lck  je.stat.csv

# rm <KVROOT>/mystore/sn1/rg1-rn1/env/*.jdb

  4. ネットワーク・リストアを使用するか、バックアップからリカバリを実行します。バックアップからのリカバリは、管理ノードのリカバリには機能しません。

    • ネットワーク・リストアを使用したリカバリ

      破損したノードが、使用可能な他のレプリケーション・ノードを持つレプリケーション・グループに属している場合、ネットワーク・リストアを使用してデータ破損からリカバリできます。ネットワーク・リストアは自動リカバリ・タスクです。破損した環境でデータベース・ファイルをすべて削除したら、CLIに接続し、破損したノードを再起動するのみで済みます。

      レプリケーション・ノードの場合: 

      kv-> plan start-service -service rg1-rn1

      管理の場合: 

      kv-> plan start-service -service rg1-rn1

    • バックアップからのリカバリ(RNのみ)

      ストアでレプリケーション・ノードのシャードに別のメンバーがない場合、またはデータ破損が原因でシャード内のすべてのノードで障害が発生した場合、以前に作成したスナップショットからノードの環境をリストアする必要があります。詳細は、ストアのリカバリを参照してください。

      データ破損が原因で障害が発生した管理をリカバリするには、機能している管理がストア内にあることが必要です。スナップショットでは、管理データは取得されません。