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

27.3. スタンバイサーバの設定

standby_mode (boolean)

PostgreSQL サーバをスタンバイとして起動するかどうかを指定します。 このパラメータが on の場合、サーバはアーカイブWALファイルの最後に到達してもリカバリを終了せず、restore_command の実行、および/あるいは、 primary_conninfo で指定されたプライマリサーバへ接続することによって、新しいWALセグメントの取得を継続しようとします。

primary_conninfo (string)

スタンバイサーバがプライマリサーバに接続するための接続文字列を指定します。 この文字列は、32.1.1. 接続文字列で説明されている書式で記述されます。 この文字列に何のオプションも指定されていない場合、これに対応する環境変数 (32.14. 環境変数 参照) が確認されます。 もし、環境変数も設定されていない場合、デフォルトの値が使われます。

接続文字列では、プライマリサーバのホスト名(またはアドレス)、スタンバイサーバのデフォルトと異なるのであればポート番号も指定する必要があります。 また、プライマリサーバ上で適切な権限を保有するロールのユーザを指定しなければなりません (26.2.5.1. 認証 参照)。 プライマリサーバが要求するのであれば、パスワードも記述される必要があります。 パスワードは primary_conninfo に記述することもできますし、スタンバイサーバ上の分離されたファイル ~/.pgpass に記述することもできます (データベース名には replication を使います)。 primary_conninfo 文字列の中には、データベース名を指定しないでください。

standby_modeoff になっている場合、この設定は無効です。

primary_slot_name (string)

上流ノードのリソース削除を制御するためにストリーミングレプリケーション経由でプライマリに接続した場合、既存のレプリケーションスロットを使うように、必要に応じて指定します(26.2.6. レプリケーションスロットを参照)。 primary_conninfoが設定されていない場合、この設定は無効です。

trigger_file (string)

スタンバイサーバにおいて、リカバリの完了を示すトリガファイルを指定します。 もしこの値が設定されていない場合、pg_ctl promoteを使ってスタンバイサーバを昇格させることができます。 standby_modeoff の時には、この設定は無効です。

recovery_min_apply_delay (integer)

デフォルトでは、スタンバイサーバは可能な限り早くプライマリからWALレコードをリストアします。 時間遅れのデータのコピーを持つことで、データ損失エラーを修正する機会を提供するのは有用かもしれません。 このパラメータを使う事で、一定時間リカバリを遅らせることができます。単位を指定しない場合、ミリ秒として扱われます。 例えば、パラメータに5minと指定した場合、各トランザクションについて、スタンバイのシステム時刻が、マスターから報告されたコミット時刻より5分以上経過している場合のみ、スタンバイサーバはコミットを再生します。

サーバ間のレプリケーション遅延はパラメータの値を上回る可能性があり、その場合には遅延は追加されません。 遅延は、マスタサーバで書かれたWALのタイムスタンプと、スタンバイサーバの現在時刻を使って計算されていることに注意してください。 ネットワークのラグやカスケーディングレプリケーション構成によるデータ転送の遅延は、実際の待ち時間を大幅に減らすかもしれません。 もし、マスタサーバとスタンバイサーバのシステムクロックが同期されていない場合、期待値よりも早くレコードのリカバリを始めるかもしれません。 しかし、このパラメータの有用な設定値は典型的なサーバ間の時間のずれよりもずっと大きいので、それらは大きな問題ではありません。

遅延はトランザクションコミットのWALレコードだけで発生します。 他のレコードは可能な限り早く再生されるでしょう。 対応する(トランザクション)コミットレコードが適用されるまではその効果が不可視であることがMVCCの可視ルールによって保証されているため、他のレコードが可能な限り早く再生されることは問題にはなりません。

ひとたびリカバリ中のデータベースが整合性のとれた状態になれば、スタンバイサーバが昇格またはトリガーになるまで、遅延が発生します。 その後、スタンバイサーバはそれ以上待たずにリカバリを終了します。

このパラメータはストリーミングレプリケーション配信で使われることを目的としていますが、パラメータが指定されていると、すべてのケースで使用されます。 この機能を使うことによってhot_standby_feedbackが遅延され、マスタサーバの肥大化に繋がる可能性があります。両方同時に使う場合には注意して使ってください。

警告

synchronous_commitremote_applyに設定されていれば、同期レプリケーションは、この設定に影響を受けます。各COMMITは適用されるのを待つことが必要です。