他のバージョンの文書 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

名前

pg_rewindPostgreSQLのデータディレクトリを、そこから派生した他のデータディレクトリと同期する

概要

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.confwal_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_rewindlibpqで利用できる環境変数を使用します(31.14. 環境変数を参照)。

注釈

どうやって動くのか

基本的なアイデアは、同じであることがわかっているブロックを除き、すべてを新しいクラスタから古いクラスタにコピーする、というものです。

  1. 古いクラスタからタイムラインが新しいクラスタで分岐した時点より前の最後のチェックポイントから始めて、古いクラスタのWALログをスキャンしします。 各々のWALレコードについて、変更されたデータブロックを記録します。 これにより、新しいクラスタで分岐した以降に、古いクラスタで変更されたすべてのデータブロックのリストが作成できます。

  2. 変更されたすべてのブロックを新しいクラスタから古いクラスタにコピーします。

  3. clogや設定ファイルなど、リレーションファイル以外のすべてのファイルを新しいクラスタから古いクラスタにコピーします。

  4. フェイルオーバの際に作られたチェックポイントから始めて、新しいクラスタのWALを適用します。(厳密に言うと、pg_rewindはWALの適用はせず、単にバックアップラベルファイルを作るだけです。 それにより、PostgreSQLが起動する時、チェックポイントから始めてすべての必要なWALが適用されます)