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_mode
が off
になっている場合、この設定は無効です。
primary_slot_name
(string
)
上流ノードのリソース削除を制御するためにストリーミングレプリケーション経由でプライマリに接続した場合、既存のレプリケーションスロットを使うように、必要に応じて指定します(26.2.6. レプリケーションスロットを参照)。
primary_conninfo
が設定されていない場合、この設定は無効です。
trigger_file
(string
)
スタンバイサーバにおいて、リカバリの完了を示すトリガファイルを指定します。
もしこの値が設定されていない場合、pg_ctl promote
を使ってスタンバイサーバを昇格させることができます。
standby_mode
が off
の時には、この設定は無効です。
recovery_min_apply_delay
(integer
)
デフォルトでは、スタンバイサーバは可能な限り早くプライマリからWALレコードをリストアします。
時間遅れのデータのコピーを持つことで、データ損失エラーを修正する機会を提供するのは有用かもしれません。
このパラメータを使う事で、一定時間リカバリを遅らせることができます。単位を指定しない場合、ミリ秒として扱われます。
例えば、パラメータに5min
と指定した場合、各トランザクションについて、スタンバイのシステム時刻が、マスターから報告されたコミット時刻より5分以上経過している場合のみ、スタンバイサーバはコミットを再生します。
サーバ間のレプリケーション遅延はパラメータの値を上回る可能性があり、その場合には遅延は追加されません。 遅延は、マスタサーバで書かれたWALのタイムスタンプと、スタンバイサーバの現在時刻を使って計算されていることに注意してください。 ネットワークのラグやカスケーディングレプリケーション構成によるデータ転送の遅延は、実際の待ち時間を大幅に減らすかもしれません。 もし、マスタサーバとスタンバイサーバのシステムクロックが同期されていない場合、期待値よりも早くレコードのリカバリを始めるかもしれません。 しかし、このパラメータの有用な設定値は典型的なサーバ間の時間のずれよりもずっと大きいので、それらは大きな問題ではありません。
遅延はトランザクションコミットのWALレコードだけで発生します。 他のレコードは可能な限り早く再生されるでしょう。 対応する(トランザクション)コミットレコードが適用されるまではその効果が不可視であることがMVCCの可視ルールによって保証されているため、他のレコードが可能な限り早く再生されることは問題にはなりません。
ひとたびリカバリ中のデータベースが整合性のとれた状態になれば、スタンバイサーバが昇格またはトリガーになるまで、遅延が発生します。 その後、スタンバイサーバはそれ以上待たずにリカバリを終了します。
このパラメータはストリーミングレプリケーション配信で使われることを目的としていますが、パラメータが指定されていると、すべてのケースで使用されます。
この機能を使うことによってhot_standby_feedback
が遅延され、マスタサーバの肥大化に繋がる可能性があります。両方同時に使う場合には注意して使ってください。
synchronous_commit
がremote_apply
に設定されていれば、同期レプリケーションは、この設定に影響を受けます。各COMMIT
は適用されるのを待つことが必要です。