ベースバックアップ取得ツール: pg_basebackup

つづいては、PostgreSQL 9.1 で追加された、スタンバイ構成を支援するコマンドや、設定の追加・拡張について見て行きます。

ベースバックアップ取得ツール: pg_basebackup

まずは pg_basebackup コマンドについてです。

レプリケーションを始める際のスタンバイ側の初期状態を作成するために、従来は、プライマリが動作しているホスト上の OS アカウントを用いて rsync などの OS レベルの手段で複製をする必要がありました。それに対して PostgreSQL 9.1 では、OS アカウントが無くても、pg_basebackup コマンドを用いることで、データベース用の接続を用いてリモートノードの複製を取得することができるようになりました。

また、複製を取得している最中にプライマリに加えられた変更までを反映した、整合性を持ったスナップショットとしてのバックアップを取得する場合でも、従来は WAL アーカイブの設定や pg_startbackup(), pg_stopbackup() といった一定の手順を踏む必要がありましたが、pg_basebackup コマンドでは "-x" オプションを指定することで、それらと同等の処理を自動的に行ってくれるようになり、とても便利になりました。

なお、ストリーミング・レプリケーションのベースとして使うならば、"-x" オプションは指定しなくても、ストリーミング・レプリケーションを開始後にスタンバイは不足分の WAL レコードをプライマリから取得・適用して最新状態にキャッチアップするので問題はありません。付けるとむしろ (pg_switch_xlog() や CHECKPOINT の分だけ) 若干ながら I/O 負荷は上がるのですが、整合性のとれた状態でバックアップを取るために、本稿の例では、いずれもオプションを付けて実行しています。

コマンド経由の昇格指示: pg_ctl promote

従来は、スタンバイノードをプライマリノードに昇格させる際には、pg_standby コマンドの "-t" オプションや recovery.conf ファイルの "trigger_file" パラメータで指定したパスにファイルを touch することをトリガとしていました。この方法ですと、トリガファイルの有無を一定秒数ごとにポーリングして調べていたため、指示を発してから実際の昇格処理が開始されるまでの間に、わずかに遅れが出ていました。PostgreSQL 9.1 からは、"pg_ctl promote" コマンドを用いることで、直接にデータベースプロセスに指示を出して昇格させることができるようになりました。この実装では、シグナルを使ってデータベースデーモンに昇格を指示するので、即座に昇格の処理が開始されるように改善されています。

フェイルオーバー後の再構築なしでの再接続

PostgreSQL 9.0 まででは、プライマリが障害を起こしたためにスタンバイを新しいプライマリとして昇格させた場合に、たとえデータの欠損がなかったとしても、古い方のプライマリのデータを一旦消して、あらためて新しいプライマリからデータを取得することでスタンバイを再構築しなおす必要がありました。

これは、データ量が多くてベースのコピーに時間がかかる場合や、プライマリの負荷が大きい場合には、好ましくありません。そこで PostgreSQL 9.1 では、同期レプリケーションで異常終了したプライマリや、非同期レプリケーションであっても、コミット済みの変更に対応する WAL がスタンバイ側へすでに書きこまれていた場合には、古い方のプライマリを、新たにそのままスタンバイノードとして再利用できるようになりました。

スタンバイとしてのリカバリを実行する際には、障害が起きた際のタイムラインではなく、新しいプライマリが昇格の際に採用した最新のタイムラインに沿ってリカバリを行う必要があり、これを指示するのが recovery_target_timeline='latest' の設定となります。この場合には、タイムラインの遷移を記録している history ファイルをプライマリから取得する必要があるため、restore_command の設定もあわせて必要になります。