★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

19.6. レプリケーション

これらの設定は組み込みのストリーミングレプリケーション機能の動作を制御します(26.2.5. ストリーミングレプリケーションを参照ください)。 サーバ群のサーバはマスターかスタンバイのいずれかです。マスターはデータを送出する一方、複数のスタンバイは複製されたデータを常に受け取ります。カスケードレプリケーション(26.2.7. カスケードレプリケーションを参照)が使用されている場合、スタンバイサーバ群は受け取り手でもあり、送り手でもあります。 パラメータは主として送出サーバとスタンバイサーバ用ですが、いくつかのパラメータはマスターサーバのみに効力を発します。 必要とあればクラスターに渡って問題なく設定を変化させることができます。

19.6.1. 送出サーバ群

これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るいかなるサーバ上で設定することができます。マスターは常に送出サーバであるため、パラメータは常にマスター上に設定されなければなりません。これらのパラメータの役割と意味はスタンバイが後にマスターに昇格しても変わりません。

max_wal_senders (integer)

複数のスタンバイサーバ、またはストリーミングを基盤とする予備(バックアップ)クライアントからの同時接続を受ける接続最大値を設定します(つまり、同時に稼動するWAL送信プロセスの最大値です)。 デフォルトはゼロです。その意味するところはレプリケーションは無効です。 WAL送出プロセスは接続の総数カウントに考慮されるため、max_connectionsを越えたパラメータの設定できません。 クライアント接続が突然切断されると、タイムアウトするまで孤児接続スロットが残ってしまうかもしれません。 ですから、このパラメータは想定されるクライアント数の最大値よりも少し大きめにして、切断されたクライアントが直ちに再接続できるようにした方が良いでしょう。 このパラメータはサーバ起動時のみ設定可能です。 スタンバイサーバからの接続を許可するには、wal_levelreplica以上に設定しておかなければなりません。

max_replication_slots (integer)

サーバが使用できるレプリケーションスロット(26.2.6. レプリケーションスロット参照)の最大数を指定します。デフォルトは0です。 このパラメータはサーバ起動時のみ設定可能です。 レプリケーションスロットが使用できるためには、wal_levelreplica以上に設定しなければなりません。 現在存在しているレプリケーションスロットの数よりも少ない値を設定すると、サーバは起動しません。

wal_keep_segments (integer)

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

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

wal_sender_timeout (integer)

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

track_commit_timestamp (bool)

トランザクションのコミットタイムを記録します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトはoffです。

19.6.2. マスターサーバ

これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るマスター/プライマリサーバ上で設定することができます。 これらパラメータに加え、wal_levelはマスターサーバ上で適切に設定される必要があり、オプションとしてWALアーカイブを有効にしてもかまいません(19.5.3. アーカイビングを参照してください)。 スタンバイサーバがマスターサーバになるかもしれない状況に備え、それらのパラメータをスタンバイサーバで設定したいと考えたとしても、スタンバイサーバ上でのパラメータの値は意味をなしません。

synchronous_standby_names (string)

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

このパラメータは、以下の構文のいずれかを用いてスタンバイサーバのリストを指定します。

num_sync ( standby_name [, ...] )
standby_name [, ...]

ここで、num_syncは、トランザクションが応答を待機する必要のある同期スタンバイの数です。 standby_nameは、スタンバイサーバの名前です。 たとえば3 (s1, s2, s3, s4)とすると、s1s2s3s4の中から選ばれた優先順位の高い3つのスタンバイサーバがWALレコードを受信するまでコミットは待機します。

2番目の構文は、PostgreSQL9.6よりも前のバージョンで用いられていたもので、依然としてサポートされています。 最初の構文でnum_syncを1とした時と同じです。 たとえば1 (s1, s2)s1, s2は同じ意味です。 どちらにおいても、s1s2が同期スタンバイとして選ばれます。

この目的のスタンバイサーバの名前は、スタンバイサーバのWAL receiverのprimary_conninfoで設定されるのと同じく、スタンバイサーバのapplication_name設定となります。 一意性を強要する仕組みにはなっていません。 重複があった場合、一致したスタンバイは優先順位が高いと見なされますが、どれが選ばれるかは非決定的です。 特別の記載である*は、walreceiverのデフォルトのアプリケーション名を含めて、全てのapplication_nameにマッチします。

注記

各々のstandby_nameは、*である場合を除き、SQL識別子の形式を取らなければなりません。 二重引用符を用いることもできます。 しかし、二重引用符の有無に関わらず、standby_nameとスタンバイのアプリケーション名の比較は、大文字小文字の区別なしに行われることに注意してください。

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

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

vacuum_defer_cleanup_age (integer)

VACUUM および HOT更新が不要行バージョンの回収を決めるのを延期するトランザクションの数を指定します。 デフォルトはゼロトランザクションで、つまり、開いている全てのトランザクションから不可視になった不要行バージョンは速やかに削除されうることを意味します。 26.5. ホットスタンバイに記載されているように、ホットスタンバイサーバをサポートしている場合、プライマリサーバ上で非ゼロ値に設定したい場合があります。 そうすることで、スタンバイ上での問い合わせが、行の早期回収によるコンフリクトを被ることなく完了するように時間を与えます。 しかし、値はプライマリーサーバ上で発生している書き込みトランザクションの観点から計測されるため、スタンバイの問い合わせにたいして猶予時間がどのくらい有効となるかは予測できません。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

このパラメータを使う代わりにスタンバイサーバ上に hot_standby_feedbackの設定を考慮する必要もあります。

old_snapshot_thresholdで指定された年齢に達したデッドタプルのクリーンアップを妨げることはありません。

19.6.3. スタンバイサーバ

これらの設定はレプリケーションデータを受け取るスタンバイサーバの動作を管理します。 マスターサーバ上のこれらの値は無意味です。

hot_standby (boolean)

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

max_standby_archive_delay (integer)

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

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

max_standby_streaming_delay (integer)

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

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

wal_receiver_status_interval (integer)

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

hot_standby_feedback (boolean)

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

カスケードレプリケーションが使用されている場合、フィードバックは最終的にプライマリーに到達するまで上位サーバに転送されます。スタンバイは上位に転送する以外、受け取ったフィードバックを他に使用しません。

この設定は、プライマリのold_snapshot_thresholdの挙動を上書きしません。 プライマリの年齢上限を超えたスタンバイ上のスナップショットは無効となる可能性があり、その場合スタンバイにおいてトランザクションのキャンセルを引き起こします。 これは、old_snapshot_thresholdが、無効行によってデータ溢れが起こる時刻の絶対的な制限を提供することを意図しているからです。 そうでなければ、スタンバイの設定によってこの目的は成立しなくなってしまいます。

wal_receiver_timeout (integer)

指定されたミリ秒より長い活動していないレプリケーション接続は停止します。 このことは受信するスタンバイサーバがプライマリノードの機能停止、またはネットワーク停止を検出するのに便利です。 値ゼロは時間切れメカニズムを無効にします。このパラメータはpostgresql.confまたはサーバのコマンドラインのみで設定可能です。 デフォルト値は60秒です。

wal_retrieve_retry_interval (integer)

WALデータがソース(ストリーミングレプリケーション、ローカルのpg_xlog、またはWALアーカイブ)から取得できない時に、スタンバイサーバがWALデータ受信をリトライするまでにどの位の時間待つべきかを指定します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルト値は5秒です。 特に指定がなければ単位はミリ秒です。

このパラメータは、リカバリ対象のノードにおいて、新しいWALデータが読み込み可能になるまでの待ち時間を制御する必要のある時に有用です。 たとえば、アーカイブリカバリにおいては、このパラメータの値を小さくすることにより、新しいWALログファイルを検出する際にリカバリの応答を早くすることができます。 WALの生成頻度が少ないシステムでは、この値を大きくすることにより、WALアーカイブへのアクセス頻度を減らすことができます。 これは、たとえば基盤へのアクセス回数が課金対象になるクラウド環境において、有用です。