★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 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

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

standby_mode (boolean)

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

primary_conninfo (string)

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

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

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

primary_slot_name (string)

上流ノードのリソース削除を制御するためにストリーミングレプリケーション経由でプライマリに接続した場合、既存のレプリケーションスロットを使うように、必要に応じて指定します(項25.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 の機能を使うことによって遅延されますが、マスタサーバの肥大化に繋がる可能性がありますので、注意が必要です。