PostgreSQL 9.4.5文書 | |||
---|---|---|---|
前のページ | 上に戻る | 第 18章サーバの設定 | 次のページ |
これらの設定は組み込みのストリーミングレプリケーション機能の動作を制御します(項25.2.5を参照ください)。 サーバ群のサーバはマスターかスタンバイのいずれかです。マスターはデータを送出する一方、複数のスタンバイは複製されたデータを常に受け取ります。カスケードレプリケーション(項25.2.7を参照)が使用されている場合、スタンバイサーバ群は受け取り手でもあり、送出先でもあります。 パラメータは主として送出先とスタンバイサーバ用ですが、いくつかのパラメータはマスターサーバのみに効力を発します。 必要とあればクラスターに渡って問題なく設定を変化させることができます。
これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るいかなるサーバ上で設定することができます。マスターは常に送出サーバであるため、パラメータは常にマスター上に設定されなければなりません。これらのパラメータの役割と意味はスタンバイが後にマスターに昇格しても変わりません。
複数のスタンバイサーバ、またはストリーミングを基盤とする予備(バックアップ)クライアントからの同時接続を受ける接続最大値を設定します(つまり、同時に稼動するWAL送信プロセスの最大値です)。 デフォルトはゼロです。その意味するところはレプリケーションは無効です。 WAL送出プロセスは最大接続数を数えているため、max_connectionsを越えたパラメータの設定できません。 クライアント接続が突然切断されると、タイムアウトするまで孤児接続スロットが残ってしまうかもしれません。 ですから、このパラメータは想定されるクライアント数の最大値よりも少し大きめにして、切断されたクライアントが直ちに再接続できるようにした方が良いでしょう。 このパラメータはサーバ起動時のみ設定可能です。 スタンバイサーバからの接続を許可するには、wal_levelがarchive以上に設定しておかなければなりません。
サーバが使用できるレプリケーションスロット(項25.2.6参照)の最大数を指定します。デフォルトは0です。 このパラメータはサーバ起動時のみ設定可能です。 レプリケーションスロットが使用できるためには、wal_levelを archive以上に設定しなければなりません。 現在存在しているレプリケーションスロットの数よりも少ない値を設定すると、サーバは起動しません。
ストリーミングレプリケーションにおいて、スタンバイサーバが過去のファイルセグメントを取得する必要がある場合に備え、pg_xlogディレクトリに保持しておくファイルセグメント数の最小値を指定します。 それぞれのセグメントは通常16メガバイトです。 もし送出サーバに接続しているスタンバイサーバがwal_keep_segmentsセグメントを越えて遅延した場合、送出サーバはスタンバイサーバが今後とも必要とするWALセグメントを削除する可能性があります。 この場合、レプリケーション接続は終了させられます。結果として下流に対する接続が同時に結果として終了されることがあります。(しかし、WALアーカイブが使用されていれば、スタンバイサーバはアーカイブからセグメントを取り出し、復旧することができます。)
pg_xlogに保持され続けるセグメントの最小値のみを設定します。 システムはWALアーカイブのため、またはチェックポイントからの復旧のため、より多くのセグメント保持が必要となることがあります。もしwal_keep_segmentsが(デフォルトの)ゼロの場合、システムは待機目的でのいかなる追加セグメントも保持しません。 従って、スタンバイサーバが使用できる古いWALセグメントの多くは、前回のチェックポイントの場所とWALアーカイブの状態を捕捉する機能になります。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
指定されたミリ秒単位の値より長く非活動のレプリケーション接続を停止します。 スタンバイサーバのクラッシュ、またはネットワークの停止を送出サーバが検出することにこれが役立ちます。 値ゼロはタイムアウト機能を無効にします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は60秒です。
これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るマスター/プライマリサーバ上で設定することができます。 これらパラメータに加え、wal_levelはマスターサーバ上で適切に設定される必要があり、任意的にWALアーカイブがサーバとしても有効になります(項18.5.3を参照してください)。 スタンバイサーバがマスターサーバになるかもしれない状況に備え、それらのパラメータをスタンバイサーバで設定したいと考えたとしても、スタンバイサーバ上でのパラメータの値は意味をなしません。
項25.2.8で説明されているように、同期レプリケーションをサポート可能なコンマで区切られたリストでスタンバイサーバの名前を指定します。 いつの時点においても、最低限一つの活動している同期スタンバイサーバが存在します。 コミットを待機しているトランザクションは、このスタンバイサーバがそのデータの受信を確認してから処理の継続が許可されます。 同期スタンバイサーバはこのリストで一番目に名前が挙げられていており、現時点で接続され、そしてデータをリアルタイムでストリーミングしているものです(pg_stat_replication ビューにおいてストリーミング状態として示されています)。 このリストの後の方に記載されているその他のスタンバイサーバは潜在的に同期スタンバイサーバになることを示しています。 もし現在の同期スタンバイサーバが理由にかかわらず切断された場合、次に順位の高いスタンバイサーバがすぐに取って代わります。 二つ以上のスタンバイサーバ名を指定することでかなりの高可用性が得られます。
この目的のスタンバイサーバの名前は、スタンバイサーバのWAL receiverのprimary_conninfoで設定されるのと同じく、スタンバイサーバのapplication_name設定となります。 一意性を強要する仕組みにはなっていません。 walreceiverのデフォルトのアプリケーション名を含めて、特別の記載である*は全てのapplication_nameにマッチします。
ここに同期スタンバイ名が指定されていない場合、同期レプリケーションは有効とはならず、トランザクションコミットはレプリケーションを待機しません。これがデフォルトの設定です。同期レプリケーションが有効であっても、synchronous_commitパラメータをlocal または offに設定することにより、個別のトランザクションをレプリケーションに対して待機しないように設定できます。
このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
VACUUM および HOTの更新が不要行バージョンの清掃と差があるかを決めるトランザクションの数を指定します。デフォルトはゼロトランザクションです。この意味は、不要行バージョンは速やかに削除され、即いかなる開いているトランザクションから不可視となります。 項25.5に記載されているように、ホットスタンバイサーバをサポートしている場合、非ゼロ値に設定したい場合があります。早期に掃除された行のため、衝突を回避するためスタンバイ上での問い合わせが完了するのにより時間を割くことができます。しかし、値はプライマリーサーバ上で発生している書き込みトランザクションの観点から計測されるため、スタンバイの問い合わせにたいして猶予時間がどのくらい有効となるかは予測できません。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
このパラメータの使用の代わりにスタンバイサーバ上に hot_standby_feedbackの設定を考慮する必要もあります。
これらの設定はレプリケーションデータを受け取るスタンバイサーバの動作を管理します。 マスターサーバ上のこれらの値は無意味です。
項25.5に記載されている通り、リカバリの最中に接続し、そして問い合わせを実行できるか否かを設定します。デフォルト値はoffです。 このパラメータはサーバ起動時のみ設定可能です。これは、アーカイブリカバリ期間、又は待機モードにある場合にのみ効果をもたらします。
ホットスタンバイが稼動している場合、このパラメータは項25.5.2で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_archive_delayはWALデータをWALアーカイブから読み込んでいる時に適用されます(従って最新ではありません)。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
max_standby_archive_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、任意の1つのWALセグメントのデータに適用される最大許可時間です。従って、ある問い合わせがWALセグメント内で時間的に初期の段階で大幅な遅延となった場合、その後の衝突する問い合わせの猶予時間はましてさらに短くなります。
ホットスタンバイが稼動している場合、このパラメータは項25.5.2で記載されているように、まさに適用されようとしているWALエントリと衝突するスタンバイサーバの問い合わせをキャンセルするにはどれだけ待機しなければならないかを設定します。 max_standby_streaming_delayはWALデータをストリーミングレプリケーションから受け取っている時に適用されます。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまでスタンバイサーバが待ち続けられるようにします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
max_standby_streaming_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。むしろ、プライマリサーバから一度受け取られたWALデータを適用するための最大許可時間です。 従って、ある問い合わせがWALセグメントにおいてそれまでに大幅な遅延となった場合、それに続いて衝突する問い合わせは、スタンバイサーバがふたたび遅れを取り戻すまで、猶予時間はさらに短くなります。
プライマリー、または上位サーバに対してレプリケーションの進捗情報を送信するため、スタンバイ上のWAL受信プロセスの最小頻度を指定します。ここで、 pg_stat_replicationビューにより確認することが可能です。 スタンバイサーバは既に書き込まれた最終のログ位置を報告し、その最終位置がディスクにフラッシュされ、その最終位置が適用されます。 このパラメータの値がそれぞれの報告間における秒単位の最大の時間間隔です。 書き込み、またはフラッシュ位置が変更される毎に更新が行われます。 あるいは、少なくともこのパラメータで設定された頻度で行われます。 このパラメータをゼロに設定すると、ステータスの更新を完全に無効化します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトの値は10秒です。
ホットスタンバイがスタンバイサーバ上で現在処理を行っている問い合わせについて、プライマリーまたは上位サーバにフィードバックを送るか否かを指定します。 このパラメータはレコードの後片付けに起因する問い合わせの取り消しを排除するために使用することができます。 しかし、いくつかの作業負荷に対してはプライマリーサーバ上でのデータベース肥大の原因となります。 フィードバックメッセージはwal_receiver_status_interval毎に、2回以上送信されません。 デフォルトの値はoffです。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
カスケードレプリケーションが使用されている場合、フィードバックは最終的にプライマリーに到達するまで上位サーバに転送されます。スタンバイは上位に転送以外、受け取ったフィードバックを他に使用しません。
指定されたミリ秒より長い活動していないレプリケーション接続は停止します。 このことは受信するスタンバイサーバがプライマリノードの機能停止、またはネットワーク停止を検出するのに便利です。 値ゼロは時間切れメカニズムを無効にします。このパラメータはpostgresql.confまたはサーバのコマンドラインのみで設定可能です。 デフォルト値は60秒です。