他のバージョンの文書 15 | 14 | 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_rewind

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

概要

pg_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata=directory | --source-server=connstr }

説明

pg_rewindは、PostgreSQLのクラスタのタイムラインが分岐した後、クラスタをその複製のクラスタに同期するためのツールです。 典型的なシナリオとしては、フェイルオーバ後、新しいマスターに追従するスタンバイとして、古いマスターサーバをオンラインに戻す、というのがあります。

実行結果は、ターゲットデータディレクトリをソースディレクトリと置き換えたのと等しくなります。 リレーションファイルのうちの変化のあったブロックだけがコピーされます。 それ以外のすべてのファイルは、設定ファイルを含め、すべてのファイルがコピーされます。 新しいベースバックアップを取ったり、rsyncのようなツールを使う場合と比較して、pg_rewindはクラスタ内の変更されていないブロックを読出す必要がないという利点があります。 データベースが大きく、クラスタ間で変更されているブロックの割合が小さい場合には、極めて高速になります。

pg_rewindはソースとターゲットクラスタ内のタイムラインヒストリーを調べ、それらがどの時点で異なるものになったのかを調べます。 差異が発生した分岐点までずっと遡ることにより、ターゲットクラスタ内のpg_walディレクトリ内の分岐点に到達するWALを見つけようとします。 変化の分岐点は、ターゲット側のタイムライン中、ソース側のタイムライン中、あるいはそれら共通の祖先の中に見つかる可能性が高いです。 分岐点のあと間をおかずシャットダウンされたような典型的なフェイルオーバのシナリオにおいては、これは特に問題になりません。 しかし、分岐点の後にターゲットクラスタが長時間運用されていた場合には、古いWALファイルはもう存在しないかもしれません。 この場合は、WALアーカイブから手動でpg_walディレクトリにコピーすることができます。 あるいは、recovery.confを設定することにより、起動時に取得できます。 pg_rewindの利用は、フェイルオーバに留まりません。 たとえば、スタンバイサーバは昇格してから書き込みトランザクションを実行し、再びスタンバイになるために巻き戻すこともできます。

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が失敗した場合、ターゲットのデータフォルダーはリカバリ可能な状態でない可能性があります。 このような場合は、最新のバックアップを取ることをお勧めします。

pg_rewindは直接書き込めないファイルが見つかるとすぐに失敗します。 たとえば、ソースサーバとターゲットサーバが読み取り専用のSSLキーと証明書に同じファイルマッピングを使用する場合に発生します。 そのようなファイルがターゲットサーバ上に存在する場合、それらを削除してからpg_rewindを実行することをお勧めします。 巻き戻しを行った後、それらのファイルの一部がソースからコピーされている可能性があります。 その場合は、コピーされたデータを削除して、巻き戻し前に使用していたリンクのセットを元に戻す必要があります。

オプション

pg_rewindは以下のコマンドラインオプションを受け付けます。

-D directory
--target-pgdata=directory

このオプションは、同期するターゲットデータディレクトリを指定します。 ターゲットサーバは、pg_rewindを実行する前に、正常にシャットダウンされていなければなりません。

--source-pgdata=directory

同期するソースサーバのデータディレクトリへのファイルシステム上のパスを指定します。 このオプションを使用する場合は、ソースサーバは正常にシャットダウンされていなければなりません。

--source-server=connstr

同期するソースPostgreSQLサーバへ接続するためのlibpq接続文字列を指定します。 接続は、スーパーユーザアクセスである通常の接続(レプリケーション接続でない)でなければなりません。 ソースサーバは稼働中でなければならず、またリカバリモードであってはいけません。

-n
--dry-run

ターゲットディレクトリを実際に更新する以外はすべてのことを行います。

-P
--progress

進行状況のレポートを有効にします。このオプションを有効にすると、データをソースクラスタからコピーする際のおおよその進行状況をレポートします。

--debug

主に開発者がpg_rewindをデバッグするのに役立つ冗長なデバッグ出力を印字します。

-V
--version

バージョン情報を表示して終了します。

-?
--help

ヘルプを表示して終了します。

環境

--source-serverオプションを使用する場合、pg_rewindlibpqで利用できる環境変数を使用します(33.14を参照)。

注釈

どうやって動くのか

基本的なアイデアは、ファイルシステムレベルの変更を、すべてをソースクラスタからターゲットクラスタにコピーする、というものです。

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

  2. ファイルシステムへの直接アクセス(--source-pgdata)かSQL (--source-server)を使って、変更のあったすべてのブロックを、ソースクラスタからターゲットクラスタにコピーします。

  3. pg_xactや設定ファイルなど、それ以外のすべてのファイルをソースクラスタからターゲットクラスタにコピーします。(リレーションファイル以外のすべて)

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