タイプ: | integer |
デフォルト: | 0 (0ms) |
分: | 0 (0ms) |
最大: | 2147483647 (2147483647ms) |
単位: | milliseconds (ms) |
コンテキスト: | sighup |
再起動: | false |
以来: | 12 |
デフォルトでは、スタンバイサーバは可能な限り早くプライマリからWALレコードをリストアします。時間遅れのデータのコピーを持つことで、データ損失エラーを修正する機会を提供するのは有用かもしれません。このパラメータを使う事で、決まった時間だけリカバリを遅らせることができます。例えば、パラメータに5min
と指定した場合、各トランザクションについて、スタンバイのシステム時刻が、マスターから報告されたコミット時刻より5分以上経過している場合のみ、スタンバイサーバはコミットを再生します。単位を指定しない場合、ミリ秒として扱われます。デフォルトは0で、遅延を与えません。
サーバ間のレプリケーション遅延はパラメータの値を上回る可能性があり、その場合には遅延は追加されません。遅延は、マスタサーバで書かれたWALのタイムスタンプと、スタンバイサーバの現在時刻を使って計算されていることに注意してください。ネットワークの遅延やカスケーディングレプリケーション構成によるデータ転送の遅延は、実際の待ち時間を大幅に減らすかもしれません。もし、マスタサーバとスタンバイサーバのシステムクロックが同期されていない場合、期待値よりも早くレコードのリカバリを始めるかもしれません。しかし、このパラメータの有用な設定値は典型的なサーバ間の時間のずれよりもずっと大きいので、それらは大きな問題ではありません。
遅延はトランザクションコミットのWALレコードだけで発生します。他のレコードは可能な限り早く再生されるでしょう。対応する(トランザクション)コミットレコードが適用されるまではその効果が不可視であることがMVCCの可視ルールによって保証されているため、他のレコードが可能な限り早く再生されることは問題にはなりません。
ひとたびリカバリ中のデータベースが整合性のとれた状態になれば、スタンバイサーバが昇格またはトリガーになるまで、遅延が発生します。その後、スタンバイサーバはそれ以上待たずにリカバリを終了します。
このパラメータはストリーミングレプリケーション配信で使われることを目的としていますが、パラメータが指定されていると、クラッシュリカバリを除くすべてのケースで使用されます。この機能を使うことによってhot_standby_feedbackが遅延され、マスタサーバの肥大化に繋がる可能性があります。両方同時に使う場合には注意して使ってください。
synchronous_commitがremote_apply
に設定されていれば、同期レプリケーションは、この設定に影響を受けます。各COMMIT
は適用されるのを待つことが必要です。
このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
On StackOverflow
On pgsql-hackers
- Re: [Bug Fix]standby may crash when switching-over in certain special cases
- doc: Mention clock synchronization recommendation for hot_standby_feedback
- Re: [HACKERS] make async slave to wait for lsn to be replayed
- Re: doc: Mention clock synchronization recommendation for hot_standby_feedback
- Re: speed up a logical replica setup