操作ミスなどによってデータの更新処理を間違ってしまうようなケースがあります。削除する対象を間違って必要なデータを削除してしまったりなど誰にでも経験があると思います。Recoveryと呼ばれる特定の時点の状態にデータベースを復旧する機能があります。この機能を利用すると、間違ってデータを消してしまう前の状態にデータベースを復旧することができます。今回は簡単な例を用いてリカバリ処理の流れを追ってみます。検証環境PITRで利用するデータの格納先を以下に示します。データベースクラスタ/data/pgdata1/データベースクラスタの退避先/data/pgdata1.bk20170528/WALファイル/data/pgdata1/pg_xlog/アーカイブファイル/bkup/pgdata1/pg_arch/ベースバックアップ/bkup/20170528_pgdata1_backup/今回の操作の時系列を以下にまとめます。テーブルの作成と初期データ挿入PITRの動作検証用のテーブル(テーブル名:testtbl)を1つ作成し、初期データを3件挿入します。リカバリポイントが分かりやすいように、テーブルにはデータを挿入したタイムスタンプを格納するカラムを持たせます。\dtリレーションがありません。データベースクラスタのベースバックアップを取得します。ベースバックアップを実行するときに、PostgreSQLを停止する必要はありません。いう名前でバックアップします。ファイルから、リカバリに不要なものが除外されたファイルとなります。正常なテーブル更新処理ベースバックアップ取得後にデータの挿入処理を続けます。ここまでは処理として何の問題もないと仮定します。これを削除しようとしたが、間違って1件目のデータを削除してしまったとします。\q-bash-4.2$この状態からPITRでリカバリを行い、データベースを正しい状態に戻します。データベースのリカバリこれからデータベースをデータが正しい時の状態にリカバリします。使用するのは、ベースバックアップ、最新のWALファイル、最新のアーカイブファイル、リカバリ設定ファイル(recovery.conf)の4種類です。0時47分00秒)の状態に戻します。Recoveryと呼びます。PostgreSQLの停止データベースを復旧するに当たり、まずはPostgreSQLを停止します。データベースクラスタの退避データベースクラスタ内のデータはWALファイル(/data/pgdata1/pg_xlog/)以外はもう使用しません。念のためデータベースクラスタ全体をリネームして退避しておきます。これはリカバリが成功してから消せば良いです。ベースバックアップからのリストアpg_basebackupコマンドで取得したベースバックアップをリストアします。リストアといってもベースバックアップのデータをデータベースクラスタのパス(/data/pgdata1/)にコピーするだけです。最新のWALファイルと最新のアーカイブファイルを使用してロールフォワード(データの更新ログを元にデータベースを再更新)します。ベースバックアップを取得した時点のWALファイルは使用しないためフォルダごと削除してしまいます。先ほど退避しておいたデータベースクラスタからWALファイルだけを取り出してデータベースクラスタにコピーします。ファイルを作成します。このファイルに、どのアーカイブファイルを使用してリカバリするか、どの時点(時刻)にリカバリするかを記述します。0時47分00秒に戻したいとします。ディレクトリに格納されています。PostgreSQLの起動ここまででPITRに必要な情報が揃ったため、PostgreSQLを起動します。起動時にrecovery.confを読み込んでPITRが実行されます。自動でリネームされます。そのため、これ以降PostgreSQLを再起動しても、間違ってまたリカバリが実行されることはありません。リカバリ後のデータの確認ではデータベースに接続してデータの状態を確認します。間違って挿入してしまった9件目のデータも削除されていることが分かります。アーカイブファイルとWALファイルに書かれた更新情報を使用して、4~8件目のデータ挿入処理を実行しています。データベースが正しい状態になっています。6.2▲setupのメニューに戻る▲プロフィールらのっち@ranocci損害保険会社のIT企画部に勤務するSEです。