チェックポイントファイル
チェックポイントは、Helixサーバのデータベース内のメタデータを作成しなおすのに必要なすべての情報を格納しているファイルです。チェックポイントを作成すると、そのデータベースはロックされます。これは、そのデータベースの完全に一貫したスナップショットを確実に取得できるようにするためです。
バージョン化ファイルはチェックポイントとは別にバックアップされます。つまり、チェックポイントはバージョン化ファイルの内容を含まないということであり、したがってバージョン化ファイルをチェックポイントから復元することはできません。 ただし、すべてのチェンジリスト、ラベル、ジョブなどは、チェックポイントから復元することができます。
確実に完全なデータベースを復元するには、ディポにおけるバージョン化ファイルと同じ時点かそれ以前に作成されたチェックポイントを使用する必要があります。つまり、バージョン化ファイルのバックアップを開始する前に、データベースのチェックポイントを作成してその生成を完了しておく必要があるということです。
ジャーナルが大きくなり過ぎないようにするには、チェックポイントを定期的に作成することが重要です。システムをバックアップする直前にチェックポイントを作成することを推奨します。
チェックポイントを作成する
チェックポイントが自動的に作成されることはありません。手動またはその他の方法で、チェックポイント作成コマンドをHelixサーバマシン上で実行する必要があります。チェックポイントを作成するには、-jcフラグ(ジャーナル作成フラグ)を指定してp4dプログラムを呼び出します。
$ p4d -r server_root -jc
Perforceサービス(p4d)の動作中にチェックポイントを作成することができます。チェックポイントの作成先は、サーバルートディレクトリ(server_rootが指定されていない場合はP4ROOT)です。
チェックポイント作成時に、データベースはp4dによってロックされ、その内容がP4ROOTディレクトリ内のcheckpoint.nというファイルにダンプされます。ここでnはシーケンス番号を表します。
データベースのロックを解除する前に、p4dはジャーナルファイルをP4ROOTディレクトリのjournal.n-1というファイルにコピーし(UNIX上でジャーナルが圧縮されていない場合はジャーナルファイルの名前を前述のファイル名に変更し)、そのうえでカレントジャーナルを切り詰めます。チェックポイントのMD5チェックサムは別のファイル(checkpoint.n.md5)に書き込まれます。そしてlastCheckpointActionカウンタが正常に完了したことを表す値に更新されます。
圧縮されたチェックポイントのMD5シグネチャを検証する際には、まずそのチェックポイントを作成したシステムに固有の行末規則を反映した形式に、チェックポイントを解凍する必要があります。(すなわち、Windowsサーバによって生成された圧縮済みチェックポイントでは、行末にCR/LFが使用されている必要があり、またUNIXシステムで生成された圧縮済みチェックポイントでは、行末にLFが使用されている必要があります。)
これにより、最新のチェックポイント(checkpoint.n)とカレントジャーナル(journal)との組み合わせに、チェックポイント作成時点のデータベースの完全な内容が確実に反映されることになります。
シーケンス番号は、そのジャーナルのロールフォワードの性質を示しています。より古いチェックポイントのデータベースを復元するには、シーケンス番号を参照します。つまり、checkpoint.6を取得したときと同じように、checkpoint.5を復元してから、checkpoint.5とcheckpoint.6の間のすべての変更を含むjournal.5をロードすることによって、Helixサーバの状態を復元できます。ほとんどの場合は、カレントデータベースを復元すれば十分です。これは、最大のシーケンス番号を持つcheckpoint.nに、現在のjournal内の変更をロールフォワードすることにより反映されます。
チェックポイントおよびジャーナルのプレフィックスやディレクトリの場所を指定するには、-jcオプションを使用します。例えば、以下のコマンドでチェックポイントを作成するとします。
$ p4d -jc prefix
この場合、チェックポイントのファイル名はprefix.ckp.n、ジャーナルファイル名はprefix.jnl.nとなります。このうちprefixの部分はコマンドラインで指定することができ、nはシーケンス番号です。prefixが指定されていない場合は、デフォルトのファイル名checkpoint.nおよびjournal.nが使用されます。プレフィックスの一部に任意のディレクトリを指定することにより、そのディレクトリにチェックポイントおよびジャーナルを格納することができます。以下に例を示します。
$ p4 -r . -J /where/my/journal/lives/journal -z -jc
/Users/bruges/server151/checkpoints/mybackup
のコマンドは、以下を返します。
Checkpointing to /Users/bruges/server151/checkpoints/mybackup.ckp.299.gz... MD5 (/Users/bruges/server151/checkpoints/mybackup.ckp.299) = 5D7D8E548D080B16ECB66AD6CE0F2E5D Rotating journal to /Users/bruges/server151/checkpoints/mybackup.jnl.298.gz...
以下のように記述することで、サーバのプレフィックスを指定することもできます。
$ p4 configure set journalPrefix=prefix
構成可能変数journalPrefixを設定すると、設定したprefixが既定のファイル名よりも優先的に使用されます。この動作は、特にマルチサーバ環境や複製環境で有用です。
Perforceサービスを実行しているマシンにログインせずにチェックポイントを作成するには、以下のコマンドを使用します。
$ p4 admin checkpoint [-z | -Z] [prefix]
p4 admin checkpointを実行すると、p4d -jcを実行した場合と同じ結果になります。ただし、p4 admin
checkpointを使用するにはサーバに接続されている必要があります。Helixサーバスーパーユーザでなければp4 adminを使用できません。
定期的にチェックポイントを作成する自動化プログラムを設定することができます。ただし、その場合、チェックポイントの作成が開始されたかどうか、プログラムの出力を常に確認するようにしてください。チェックポイントの実際のMD5チェックサムと、.md5ファイルに記録されているチェックサムを比較し、チェックポイントとともに.md5ファイルをバックアップしてください。正常に作成されたことが確認されたら、チェックポイントファイルを圧縮したり、アーカイブしたり、他のディスクに移動することができます。それとほぼ同時に、ディポのサブディレクトリに保存されたバージョン化ファイルをバックアップします。
バックアップから復元する場合、チェックポイントは、少なくともディポのファイルと同じくらい古いものでなければなりません。つまり、バージョン化ファイルがチェックポイントより新しい場合には問題は生じませんが、より古い場合には正常に復元できません。当然ながら、作成された時期のずれはできるだけ小さいほうが望ましいといえます。
チェックポイントコマンド自体が失敗する場合はすぐに、サポートを依頼してください。チェックポイントの失敗は通常、リソースに関する問題の症状であり、適切に処理されない場合、データベースが危険にさらされる可能性があります。
チェックポイントの整合性を検証するには、p4d
-jvコマンドを使用します。






