18.6. レプリケーション

スタンバイサーバまたはストリーミングベースのバックアップクライアントからの最大同時接続数（つまり同時に稼働するWAL送信プロセスの最大数）を指定します。 デフォルトは、レプリケーションが無効であることを意味する、ゼロです。 WAL送信プロセス接続総数にも計上されます。このためこのパラメータをmax_connectionsより多く設定することはできません。 このパラメータはサーバ起動時のみ設定可能です。 スタンバイサーバからの接続を許可するためにはwal_levelをarchiveまたはhot_standbyに設定しなければなりません。

WAL送信プロセスに対する動作周回間の遅延を設定します。 それぞれの周回で、WAL送信サーバはスタンバイサーバに最終周回で送った後に蓄積されたWALを送信します。 そして、wal_sender_delayミリ秒活を動停止し、そしてそれを繰り返します。 活動休止はトランザクションのコミットにより中断されますので、この設定にかかわらず、コミットされたトランザクションの結果はコミット直後すぐさま、スタンバイサーバに送られます。 デフォルトの値は1秒（1s）です。 多くのシステムでは、有効な活動停止遅延の分解能は10ミリ秒です。10の倍数でない値にwal_sender_delayを設定しても、次の10の倍数に設定したのと同じ結果となります。このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

ストリーミングレプリケーションにおいて、スタンバイサーバが過去のファイルセグメントを取得する必要がある場合に備え、pg_xlogディレクトリに保持しておくファイルセグメント数の最小値を指定します。 それぞれのセグメントは通常16メガバイトです。もしプライマリサーバに接続しているスタンバイサーバがwal_keep_segmentsセグメントを越えて遅延した場合、プライマリサーバはスタンバイサーバが今後とも必要とするWALセグメントを削除する可能性があります。 この場合、レプリケーション接続は終了させられます。（しかし、WALアーカイブが使用されていれば、スタンバイサーバはアーカイブからセグメントを取り出し、復旧することができます。）

pg_xlogに保持され続けるセグメントの最小値のみを設定します。 システムはWALアーカイブのため、またはチェックポイントからの復旧のため、より多くのセグメント保持が必要となることがあります。もしwal_keep_segmentsが（デフォルトの）ゼロの場合、システムは待機目的でのいかなる追加セグメントも保持しません。 従って、スタンバイサーバが使用できる古いWALセグメントの多くは、前回のチェックポイントの場所とWALアーカイブの状態を捕捉する機能になります。 このパラメータはリスタートポイントに影響を与えません。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

VACUUMおよびHOT更新が不必要となった行バージョンの後片付けをどれくらい遅らせるかをトランザクション数で設定します。 デフォルトはトランザクション数がゼロとなっていて、不必要となった行バージョンは可能な限り迅速に、つまり実行中のどんなトランザクションから見えなくなり次第削除されます。 項25.5で記述されているように、ホットスタンバイ構成のプライマリサーバにて、この設定を非ゼロにしたいと思う場合もあります。 そうすることで、行を早期に後片付けすることによっておこる衝突を招かずに、スタンバイサーバ上での問い合わせに対して時間をより多く割くことができます。 しかし、この値はプライマリサーバ上で発生する書き込みトランザクション数で測られるので、待機中の問い合わせにどれだけ多くの追加猶予時間を与えられるかを予想することはできません。 このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

このパラメータを使用する代わりとして、hot_standby_feedbackを設定することも同時に考慮したほうが良いでしょう。

指定されたミリ秒単位の値より長く非活動のレプリケーション接続を停止します。 スタンバイサーバのクラッシュ、またはネットワークの停止をプライマリーサーバが検出することにこれが役立ちます。 値ゼロはタイムアウト機能を無効にします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は60秒です。

時期尚早に接続が停止されることを防ぐため、スタンバイサーバでwal_receiver_status_intervalが必ず有効になっていなければなりません。 また、その値はreplication_timeoutの値未満でなければなりません。

項25.2.6で説明されているように、同期レプリケーションをサポート可能なコンマで区切られたリストでスタンバイサーバの名前を指定します。 いつの時点においても、最低限一つの活動している同期スタンバイサーバが存在します。 コミットを待機しているトランザクションは、このスタンバイサーバがそのデータの受信を確認してから処理の継続が許可されます。 同期スタンバイサーバはこのリストで一番目に名前が挙げられていており、現時点で接続され、そしてデータをリアルタイムでストリーミングしているものです（ pg_stat_replication ビューにおいてストリーミング状態として示されています）。 このリストの後の方に記載されているその他のスタンバイサーバは潜在的に同期スタンバイサーバになることを示しています。 もし現在の同期スタンバイサーバが理由にかかわらず切断された場合、次に順位の高いスタンバイサーバがすぐに取って代わります。 二つ以上のスタンバイサーバ名を指定することでかなりの高可容性が得られます。

この目的のスタンバイサーバの名前は、スタンバイサーバのwalreceiverのprimary_conninfoで設定されるのと同じく、スタンバイサーバのapplication_name設定となります。 一意性を強要する仕組みにはなっていません。 walreceiverのデフォルトのアプリケーション名を含めて、特別の記載である*は全てのapplication_nameにマッチします。

ここに同期スタンバイ名が指定されていない場合、同期レプリケーションは有効とはならず、トランザクションコミットはレプリケーションを待機しません。これがデフォルトの設定です。同期レプリケーションが有効であっても、synchronous_commitパラメータをlocal または offに設定することにより、個別のトランザクションをレプリケーションに対して待機しないように設定できます。

このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

項25.5に記載されている通り、リカバリの最中に接続し、そして問い合わせを実行できるか否かを設定します。デフォルト値はoffです。 このパラメータはサーバ起動時のみ設定可能です。これは、アーカイブリカバリ期間、又は待機モードにある場合にのみ効果をもたらします。

ホットスタンバイが稼動している場合、このパラメータは項25.5.2で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_streaming_delayはWALデータをWALアーカイブから読み込んでいる時に適用されます（従って最新ではありません）。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_standby_archive_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、任意の１つのWALセグメントのデータに適用される最大許可時間です。従って、ある問い合わせがWALセグメント内で時間的に初期の段階で大幅な遅延となった場合、その後の衝突する問い合わせの猶予時間はましてさらに短くなります。

ホットスタンバイが稼動している場合、このパラメータは項25.5.2で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_streaming_delayはWALデータをストリーミングレプリケーションから受け取っている時に適用されます。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_standby_streaming_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、一度プライマリサーバから受け取られたWALデータに適用される最大許可時間です。 従って、ある問い合わせが大幅な遅延となった場合、スタンバイサーバがふたたび遅れを取り戻すまで、その後の衝突する問い合わせの猶予時間はましてさらに短くなります。

プライマリーに対してレプリケーションの進捗についての情報を送信するため、スタンバイ上のWAL受信プロセスの最小頻度を指定します。ここで、 pg_stat_replicationビューにより確認することが可能です。 スタンドバイサーバは既に書き込まれた最終のログ位置を報告し、その最終位置がディスクにフラッシュされ、その最終位置が適用されます。 このパラメータの値がそれぞれの報告間における秒単位の最大の時間間隔です。 書き込み、またはフラッシュ位置が変更される毎に更新が行われます。 あるいは、少なくともこのパラメータで設定された頻度で行われます。 このパラメータをゼロに設定すると、ステータスの更新を完全に無効化します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は10秒です。

プライマリー上でreplication_timeoutが有効になっている場合、wal_receiver_status_intervalも有効になっていなければなりません。 そして、その値はreplication_timeoutの値未満である必要があります。

ホットスタンバイがスタンバイサーバ上で現在処理を行っている問い合わせについて、プライマリーにフィードバックを送るか否かを指定します。 このパラメータはレコードの後片付けに起因する問い合わせの取り消しを排除するために使用することができます。 しかし、いくつかの作業負荷に対してはプライマリーサーバ上でのデータベース肥大の原因となります。 フィードバックメッセージはwal_receiver_status_interval毎に、一回以上送信されません。 デフォルトの値はoffです。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。