フォールトトレランスを確保するために、PostgreSQLは多くのデータベースと同様に、データ変更の履歴を保持する特別なログブックを使用します。 データベースファイルにデータを書き込む前に、PostgreSQLサーバーはRAMに変更を蓄積し、予期しない停電によって失われないようにシリアルログファイルに書き込みます。
データベースユーザーが変更の正常な適用に関するメッセージを受信する前に、データがログに書き込まれます。 このログは、先行書き込みログまたは単にWALと呼ばれ、ログファイルはpg_xlogディレクトリに保存されます。 PostgreSQLは、変更された累積データをRAMからディスクに定期的にフラッシュします。 このデータ照合プロセスはチェックポイントと呼ばれます。 PostgreSQLがシャットダウンされるたびに、チェックポイントも実行されます。
コントロールポイントが終了した内部値に関する情報は、グローバル/ pg_controlファイルに保存されるため、データ回復の前にDBMSからこのファイルにアクセスできる必要があります。 PostgreSQLが異常に切断された場合、ログファイル（pg_xlog）からの変更がデータベースファイルに適用され、最後のチェックポイントの位置から開始されます。 このプロセスはデータ復旧と呼ばれます。
pg_controlファイルには次の情報が含まれています。
- 制御ファイル形式のバージョン、
- このファイルに書き込まれたデータのチェックサム、
- データベースファイル形式のバージョン、
- データベースインスタンスの一意の識別子、
- 現在の状態：実行中/停止中、
- 実行中および以前の制御点に対応するログ位置、
- 現在のタイムライン
- 最大可視トランザクション数（xid）、
- オブジェクトの内部カウンターの最大数（oid）、
- 作成時間
- などなど。
pg_controldataユーティリティを使用してpg_controlの内容を表示できます。
$ pg_controldata /var/lib/pgsql/9.5/data pg_control version number: 942 Catalog version number: 201510051 Database system identifier: 6242923005164171508 Database cluster state: in production pg_control last modified: Fri Apr 29 01:00:00 2016 Latest checkpoint location: EEAF/BAA5520 Prior checkpoint location: EEAF/BAA5440 ... Latest checkpoint's NextXID: 7/876524573 Latest checkpoint's NextOID: 264355612 Latest checkpoint's NextMultiXactId: 134512401 Latest checkpoint's NextMultiOffset: 547842659 ...
pg_controlの内容が失われた場合、PostgreSQLはリカバリ手順を開始できません。 データベースファイルが予期せず消失した場合（ fsync=off
パラメーターを使用した緊急シャットダウン中に発生する可能性があります）、バックアップに切り替えることが正しい方法です。 この記事は、データベースを最小限に復元する必要がある場合に役立ちますが、バックアップコピーに切り替えることはできず、データの一部を寄付できます。
pg_controlファイルは障害から保護されておらず、pg_resetxlogユーティリティまたは16進エディターを使用してのみ復元できます。 pg_resetxlogを使用すると、一部のデータが失われる場合があります。 現在のすべてのトランザクションログを拒否し、PostgreSQLが正常に作業を完了したと考えます。すべてのデータはチェックポイントが完了したかのようにファイルに書き込まれます。 また、表示可能な最大トランザクションカウンター番号を選択する必要があります。 選択したトランザクション数が大きすぎると、チェックポイント作成プロセスで行われたように、データファイルにはDBMSがRAMからディスクにまだフラッシュしていない情報が含まれません。 選択したトランザクション番号が小さすぎると、後で記録されたデータが見えなくなります。
コントロールポイントの瞬間を選択することは論理的ですが、この値はどこで取得できますか？ 標準ユーティリティpg_xlogdumpが役立ちます。これにより、WALファイルの内容を確認できます。 XLOGレコードタイプを使用して、チェックポイントレコードがある最新のファイルを選択する必要があります。
$ pg_xlogdump -r XLOG pg_xlog/$FILE ... rmgr: XLOG len (rec/tot): 80/ 106, tx: 0, lsn: EEAF/0BAA5B40, prev EEAF/0BAA5B08, desc: CHECKPOINT_ONLINE redo EEAF/BAA5B08; tli 2; prev tli 2; fpw true; xid 7/876524573; oid 264355612; multi 134512401; offset 547842659; oldest xid 686019718 in DB 16400; oldest multi 128391103 in DB 16400; oldest/newest commit timestamp xid: 0/0; oldest running xid 876524573; online
この場合、pg_resetxlogに対して次のオプションを選択できます。
$ pg_resetxlog -x 876524573 -o 264355612 -m 134512401,128391103 -n /var/lib/pgsql/9.5/data
指定されたコマンドで値を適用するには、 -n
スイッチを使用せずに、 -f
オプションを追加して実行する必要があります。 このコマンドは、pg_xlogディレクトリの内容をクリアし、pg_controlファイルに新しい値を書き込みます。 その後、データを復元せずにPostgreSQLを起動できます。
バッファーキャッシュから移動されたデータがデータベースファイルに書き込まれることが判明しないようにするために、回復のためにチェックポイントを選択した場合、インスタンスを起動する前にpg_dumpユーティリティを使用autovacuum=off
てautovacuum=off
パラメーターを設定し、論理バックアップを削除することをお勧めします。 バックアップコピーの削除中にエラーが発生した場合は、 zero_damaged_pages=on
パラメーターを使用zero_damaged_pages=on
ます。 論理バックアップを作成した後、PostgreSQLの新しいインスタンスでそれを復元する必要があります。
PostgreSQLのすべての成功した操作とあなたの指先でのバックアップ！