データベースが破損しており、バージョン化ファイルが影響を受けていない場合

データベースのみが破損した場合(つまりdb.*ファイルがクラッシュしたドライブ上に存在する一方で、シンボリックリンクを使用してバージョン化ファイルを別の物理ドライブに保存していた場合)、データベースのみを再作成する必要があります。

必要なものは以下のとおりです。

• 最後に作成されたチェックポイントファイル。これは、最新のP4ROOTディレクトリバックアップから入手できます。チェックポイントをバックアップした際に対応する.md5ファイルもバックアップしていた場合、チェックポイントのチェックサムと復元された.md5ファイルの内容を比較することにより、チェックポイントが正しく復元されたことを確認できます。
• カレントジャーナルファイル。このファイルは、P4ROOTディレクトリとは別のファイルシステム上に存在するため、P4ROOTディレクトリが存在するファイルシステムで障害が発生しても、影響を受けることはありません。

不要なものは以下のとおりです。

• バージョン化ファイルのバックアップ。これは、クラッシュの影響を受けていなければ、既に最新の状態になっています。

データベースをリカバリする

1. p4dの現在のインスタンスを停止します。

   $ p4 admin stop

   (Helixサーバスーパーユーザでなければp4 adminを使用できません。)

2. データベース(db.*)のファイル名を変更するか、そのファイルを移動します。

   $ mv your_root_dir /db.* /tmp

   チェックポイントからリカバリを開始すると、P4ROOTディレクトリにdb.*ファイルが存在しない可能性があります。古いdb.*ファイルがリカバリ中に使用されることはありませんが、復元が正常に完了するまでそれらのファイルを削除しないことを推奨します。

3. 以下のようなコマンドを使用して、チェックポイントの整合性を検証します。

   $ p4d -jv my_checkpoint_file

   コマンドによって検証される項目は以下のとおりです。

   • チェックポイントは冒頭から末尾まで読み取り可能かどうか。
   • 圧縮されている場合、正常に解凍できるかどうか。
   • MD5ファイルがある場合、そのチェックポイントのMD5と一致するかどうか。

   • 想定されるヘッダとトレーラが存在するかどうか。

     圧縮されたチェックポイントの整合性を検証するには、-zフラグと-jvフラグを組み合わせて使用します。

4. p4dに-jr(journal-restore)フラグを付けて、最近のチェックポイントとカレントジャーナルを指定して起動します。サーバルート(P4ROOT)を明示的に指定する場合、-r $P4ROOT引数を-jrフラグの前に置く必要があります。また、p4dプロセスは起動時に作業ディレクトリをサーバルートに変更するので、checkpoint_fileおよびjournal_fileをP4ROOTディレクトリからの相対パスで指定する必要があります。

   $ p4d -r $P4ROOT -jr checkpoint_file journal_file

   これにより、データベースが最後のチェックポイント作成時点の状態でリカバリされ、その後、チェックポイント作成後のジャーナルファイルのなかに記録されている変更が適用されます。

$ p4d -r $P4ROOT -jr checkpoint_file journal_file

$ p4d -r $P4ROOT -z -jr checkpoint_file.gz
$ p4d -r $P4ROOT -jr journal_file

システムをチェックする

復元は完了しました。復元が正常に完了したことを確認するには、「復元後のシステムの整合性を確認する」を参照してください。

システムの状態

最新のチェックポイントからリカバリしたデータベースは、カレントジャーナルファイルに保存されていた変更を適用すると、不具合が発生した時点の状態に戻ります。

リカバリ後のデータベースとバージョン化ファイルの両方には、クラッシュした時点までのすべての変更が反映されているはずであり、消失したデータはないはずです。復元が正常に完了した場合、lastCheckpointActionカウンタはチェックポイントの作成完了を示す値に変わります。