説明

<application>pg_rewind</application> is a tool for synchronizing a PostgreSQL cluster with another copy of the same cluster, after the clusters' timelines have diverged. A typical scenario is to bring an old primary server back online after failover as a standby that follows the new primary. pg_rewindは、PostgreSQLのクラスタのタイムラインが分岐した後、クラスタをその複製のクラスタに同期するためのツールです。 典型的なシナリオとしては、フェイルオーバー後、新しいプライマリに追従するスタンバイとして、古いプライマリサーバをオンラインに戻す、というのがあります。

After a successful rewind, the state of the target data directory is analogous to a base backup of the source data directory. Unlike taking a new base backup or using a tool like <application>rsync</application>, <application>pg_rewind</application> does not require comparing or copying unchanged relation blocks in the cluster. Only changed blocks from existing relation files are copied; all other files, including new relation files, configuration files, and WAL segments, are copied in full. As such the rewind operation is significantly faster than other approaches when the database is large and only a small fraction of blocks differ between the clusters. 巻き戻し(rewind)が成功すれば、ターゲットデータディレクトリの状態はソースデータディレクトリのベースバックアップと類似したものになります。 新しいベースバックアップを取ったり、rsyncのようなツールを使うのとは異なり、pg_rewindはクラスタ内の変更されていないリレーションブロックの比較やコピーを必要としません。 既存のリレーションファイルのうちの変化のあったブロックだけがコピーされます。それ以外のすべてのファイルは、新しいリレーションファイルや設定ファイル、WALセグメントを含め、すべてのファイルがコピーされます。 そのため、データベースが大きく、クラスタ間で変更されているブロックの割合が小さい場合には、巻き戻し操作は他の方法に比べて極めて高速になります。

<application>pg_rewind</application> examines the timeline histories of the source and target clusters to determine the point where they diverged, and expects to find WAL in the target cluster's <filename>pg_wal</filename> directory reaching all the way back to the point of divergence. The point of divergence can be found either on the target timeline, the source timeline, or their common ancestor. In the typical failover scenario where the target cluster was shut down soon after the divergence, this is not a problem, but if the target cluster ran for a long time after the divergence, its old WAL files might no longer be present. In this case, you can manually copy them from the WAL archive to the <filename>pg_wal</filename> directory, or run <application>pg_rewind</application> with the <literal>-c</literal> option to automatically retrieve them from the WAL archive. The use of <application>pg_rewind</application> is not limited to failover, e.g., a standby server can be promoted, run some write transactions, and then rewound to become a standby again. pg_rewindはソースとターゲットクラスタ内のタイムラインヒストリーを調べ、それらがどの時点で異なるものになったのかを調べます。 差異が発生した分岐点までずっと遡ることにより、ターゲットクラスタ内のpg_walディレクトリ内の分岐点に到達するWALを見つけようとします。 変化の分岐点は、ターゲット側のタイムライン中、ソース側のタイムライン中、あるいはそれら共通の祖先の中に見つかる可能性が高いです。 分岐点のあと間をおかずシャットダウンされたような典型的なフェイルオーバーのシナリオにおいては、これは特に問題になりません。 しかし、分岐点の後にターゲットクラスタが長時間運用されていた場合には、古いWALファイルはもう存在しないかもしれません。 この場合は、WALアーカイブから手動でpg_walディレクトリにコピーできます。 あるいは、-cオプションを付けてpg_rewindを実行し、WALアーカイブから自動的に取り出すこともできます。 pg_rewindの利用は、フェイルオーバーに留まりません。 たとえば、スタンバイサーバが昇格してから書き込みトランザクションを実行し、再びスタンバイになるために巻き戻すこともできます。

After running <application>pg_rewind</application>, WAL replay needs to complete for the data directory to be in a consistent state. When the target server is started again it will enter archive recovery and replay all WAL generated in the source server from the last checkpoint before the point of divergence. If some of the WAL was no longer available in the source server when <application>pg_rewind</application> was run, and therefore could not be copied by the <application>pg_rewind</application> session, it must be made available when the target server is started. This can be done by creating a <filename>recovery.signal</filename> file in the target data directory and by configuring a suitable <xref linkend="guc-restore-command"/> in <filename>postgresql.conf</filename>. pg_rewindを実行した後、データディレクトリが整合のとれた状態になるためにはWALリプレイの完了が必要です。 ターゲットサーバは再起動すると、アーカイブリカバリに入り、分岐点の前の最後のチェックポイント以降にソースサーバで生成されたWALをすべてリプレイします。 pg_rewindが実行された時にWALの中にソースサーバにないものがあり、pg_rewindのセッションではコピーできなかった場合は、ターゲットサーバが起動した時にWALを読む込めるようになっていなければなりません。 recovery.signalファイルをターゲットデータディレクトリに置き、postgresql.confに適切なrestore_commandを設定することで、これを達成できます。

<application>pg_rewind</application> requires that the target server either has the <xref linkend="guc-wal-log-hints"/> option enabled in <filename>postgresql.conf</filename> or data checksums enabled when the cluster was initialized with <application>initdb</application>. Neither of these are currently on by default. <xref linkend="guc-full-page-writes"/> must also be set to <literal>on</literal>, but is enabled by default. pg_rewindを使用するには、ターゲットサーバ上でpostgresql.confのwal_log_hintsオプションが有効になっているか、initdbでクラスタを初期化した時にデータチェックサムが有効になっていなければなりません。 どちらもデフォルトではonではありません（無効です）。 full_page_writesもon（有効）でなければなりませんが、これはデフォルトで有効です。

オプション

<application>pg_rewind</application> accepts the following command-line arguments: pg_rewindは以下のコマンドラインオプションを受け付けます。

環境

When <option>&#45;-source-server</option> option is used, <application>pg_rewind</application> also uses the environment variables supported by <application>libpq</application> (see <xref linkend="libpq-envars"/>). --source-serverオプションを使用する場合、pg_rewindは libpqで利用できる環境変数を使用します(32.15を参照)。

The environment variable <envar>PG_COLOR</envar> specifies whether to use color in diagnostic messages. Possible values are <literal>always</literal>, <literal>auto</literal> and <literal>never</literal>. 環境変数PG_COLORは診断メッセージで色を使うかどうかを指定します。 指定可能な値はalways、auto、neverです。

注釈

When executing <application>pg_rewind</application> using an online cluster as source, a role having sufficient permissions to execute the functions used by <application>pg_rewind</application> on the source cluster can be used instead of a superuser. Here is how to create such a role, named <literal>rewind_user</literal> here: オンラインのクラスタをソースとして使用してpg_rewindを実行するとき、スーパーユーザの代わりにソースのクラスタ上でpg_rewindで使われる関数を実行できる権限を持ったロールを使うことができます。 rewind_userという名前のこのようなロールの作り方を以下に示します。

CREATE USER rewind_user LOGIN;
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;