pg_rewind — PostgreSQLのデータディレクトリを、そこから派生した他のデータディレクトリと同期する
pg_rewind
[option
...] { -D
| --target-pgdata
} directory
{ --source-pgdata=
| directory
--source-server=
} connstr
pg_rewindは、PostgreSQLのクラスタのタイムラインが分岐した後、クラスタをその複製のクラスタに同期するためのツールです。 典型的なシナリオとしては、フェイルオーバ後、新しいマスターに追従するスタンバイとして、古いマスターサーバをオンラインに戻す、というのがあります。
実行結果は、ターゲットデータディレクトリをソースディレクトリと置き換えたのと等しくなります。 設定ファイルを含め、すべてのファイルがコピーされます。 新しいベースバックアップを取ったり、rsyncのようなツールを使う場合と比較して、pg_rewindはクラスタ内の変更されていないファイルを読出す必要がないという利点があります。 データベースが大きく、クラスタ間で変更されている部分がわずかの場合には、極めて高速になります。
pg_rewindはソースとターゲットクラスタ内のタイムラインヒストリーを調べ、それらがどの時点で異なるものになったのかを調べます。
そしてターゲットクラスタ内のpg_xlog
ディレクトリ内の分岐点に到達するWALを見つけようとします。
分岐点のあと間をおかずシャットダウンされたような典型的なフェイルオーバのシナリオにおいては、これは特に問題になりません。
しかし、分岐点の後にターゲットクラスタが長時間運用されていた場合には、古いWALファイルはもう存在しないかもしれません。
この場合は、WALアーカイブから手動でpg_xlog
ディレクトリにコピーすることができます。
不足しているWALファイルをアーカイブから自動的にコピーする機能は今のところサポートされていません。
pg_rewindを実行した後、最初にターゲットサーバを起動すると、そのサーバはリカバリモードに入り、分岐点以降ソースサーバで生成されたWALをすべてリプレイします。
pg_rewindが実行された時にWALがソースサーバになくてpg_rewindのセッションではコピーできなかった場合は、ターゲットサーバが起動した時にWALを読む込めるようになっていなければなりません。
適切なrestore_command
を設定したrecovery.conf
ファイルをターゲットデータディレクトリに置くことで、これを達成できます。
pg_rewindを使用するには、ターゲットサーバ上でpostgresql.conf
のwal_log_hintsオプションが有効になっているか、initdbでクラスタを初期化した時にデータチェックサムが有効になっていなければなりません。
どちらもデフォルトでは無効です。
full_page_writesも有効でなければなりませんが、これはデフォルトで有効です。
pg_rewindは以下のコマンドラインオプションを受け付けます。
-D directory
--target-pgdata=directory
このオプションは、同期するターゲットデータディレクトリを指定します。 ターゲットサーバは、pg_rewindを実行する前に、正常にシャットダウンされていなければなりません。
--source-pgdata=directory
同期するソースサーバのデータディレクトリへのパスを指定します。
--source-pgdata
を使用する場合は、ソースサーバは正常にシャットダウンされていなければなりません。
--source-server=connstr
同期するソースPostgreSQLサーバへ接続するためのlibpq接続文字列を指定します。 接続は、スーパユーザアクセスである通常の接続(レプリケーション接続でない)でなければなりません。 サーバは稼働中でなければならず、またリカバリモードであってはいけません。
-n
--dry-run
ターゲットディレクトリを実際に更新する以外はすべてのことを行います。
-P
--progress
進行状況のレポートを有効にします。このオプションを有効にすると、データをソースクラスタからコピーする際のおおよその進行状況をレポートします。
--debug
主に開発者がpg_rewindをデバッグするのに役立つ冗長なデバッグ出力を印字します。
-V
--version
バージョン情報を表示して終了します。
-?
--help
ヘルプを表示して終了します。
--source-server
オプションを使用する場合、pg_rewindは
libpqで利用できる環境変数を使用します(31.14. 環境変数を参照)。
基本的なアイデアは、同じであることがわかっているブロックを除き、すべてを新しいクラスタから古いクラスタにコピーする、というものです。
古いクラスタからタイムラインが新しいクラスタで分岐した時点より前の最後のチェックポイントから始めて、古いクラスタのWALログをスキャンしします。 各々のWALレコードについて、変更されたデータブロックを記録します。 これにより、新しいクラスタで分岐した以降に、古いクラスタで変更されたすべてのデータブロックのリストが作成できます。
変更されたすべてのブロックを新しいクラスタから古いクラスタにコピーします。
clog
や設定ファイルなど、リレーションファイル以外のすべてのファイルを新しいクラスタから古いクラスタにコピーします。
フェイルオーバの際に作られたチェックポイントから始めて、新しいクラスタのWALを適用します。(厳密に言うと、pg_rewindはWALの適用はせず、単にバックアップラベルファイルを作るだけです。 それにより、PostgreSQLが起動する時、チェックポイントから始めてすべての必要なWALが適用されます)