動的構成設定

動的構成はDCS（分散構成ストア）に格納され、すべてのクラスターノードに適用されます。

動的構成を変更するには、 patronictl edit-config ツールまたはPatroni patronictl edit-config を使用できます。

  • loop/_wait ：ループがスリープする秒数。デフォルト値：10

  • ttl ：リーダーロックを取得するTTL（秒）。自動フェールオーバープロセスが開始されるまでの時間と考えてください。デフォルト値：30

  • retry/_timeout ：DCSおよびPostgreSQL操作の再試行のタイムアウト（秒単位）。これより短いDCSまたはネットワークの問題により、Patroniがリーダーを降格させることはありません。デフォルト値：10

  • maximum/_lag/_on/_failover ：フォロワーがリーダー選挙に参加できるようになるまでに遅延できる最大バイト。

  • maximum/_lag/_on/_syncnode ：同期フォロワーが異常な候補と見なされ、正常な非同期フォロワーと交換されるまでに遅延できる最大バイト。Patroniは、フォロワーが複数いる場合は最大レプリカlsnを利用し、それ以外の場合はリーダーの現在のwallsnを使用します。デフォルトは-1です。値が0以下に設定されている場合、Patroniは同期の異常なフォロワーをスワップするアクションを実行しません。Patroniが大量のトランザクション時に同期フォロワーを頻繁に交換しないように、値を十分に高く設定してください。

  • max/_timelines/_history ：DCSに保持されるタイムライン履歴アイテムの最大数。デフォルト値：0。0に設定すると、DCSに完全な履歴が保持されます。

  • primary/_start/_timeout :フェールオーバーがトリガーされる前にプライマリが障害から回復できる時間（秒）。デフォルトは300秒です。0に設定すると、可能な場合はクラッシュが検出された直後にフェールオーバーが実行されます。非同期レプリケーションを使用する場合、フェイルオーバーによりトランザクションが失われる可能性があります。プライマリ障害の最悪のフェイルオーバー時間は次のとおりです。loop/_wait+primary/_start/_timeout+loop/_wait耐久性/可用性のトレードオフに従って値を設定します。

  • primary/_stop/_timeout ：PatroniがPostgresを停止するときに待機することが許可され、synchronous_modeが有効な場合にのみ有効な秒数。>0に設定され、synchronous_modeが有効になっている場合、停止操作がprimary/_stop/_timeoutで設定された値を超えて実行されている場合、パトローニはポストマスターにSIGKILLを送信します。耐久性/可用性のトレードオフに従って値を設定します。パラメーターが設定されていない場合、または設定されている<=0の場合、primary/_stop/_timeoutは適用されません。

  • synchronous/_mode ：同期レプリケーションモードをオンにします。このモードでは、レプリカが同期として選択され、最新のリーダーと同期レプリカのみがリーダー選挙に参加できます。同期モードでは、正常にコミットされたトランザクションがフェイルオーバー時に失われないことが保証されますが、Patroniがトランザクションの耐久性を保証できない場合、書き込みの可用性が失われます。詳細は synchronous/_mode を参照してください。

  • synchronous/_mode/_strict :利用可能な同期レプリカがない場合に同期レプリケーションが無効になるのを防ぎ、プライマリへのすべてのクライアントの書き込みをブロックします。詳細は synchronous/_mode/_strict を参照してください。

  • failsafe/_mode ： failsafe/_mode を有効にします。デフォルトは`false`です。

  • postgresql ：

    • use/_pg/_rewind ：pg_rewindを使用するかどうか。デフォルトは`false`です。

    • use/_slots ：レプリケーションスロットを使用するかどうか。PostgreSQL9.4以降のデフォルトは`true`です。

    • recovery/_conf ：フォロワーの構成時にrecovery.confに書き込まれる追加の構成設定。PostgreSQL12にはrecovery.confはもうありませんが、Patroniが透過的に処理するため、このセクションを引き続き使用できます。

    • parameters ：Postgresの構成設定のリスト。

    • pg/_hba ：Patroniが pg_hba.conf を生成するために使用する行のリスト。 hba_file PostgreSQLパラメーターがデフォルト以外の値に設定されている場合、Patroniはこのパラメーターを無視します。

      • -hostallall0.0.0.0/0md5

      • -ホストレプリケーションレプリケーター127.0.0.1/32md5 ：レプリケーションにはこのような行が必要です。

    • pg/_ident ：Patroniが pg_ident.conf を生成するために使用する行のリスト。 ident_file PostgreSQLパラメーターがデフォルト以外の値に設定されている場合、Patroniはこのパラメーターを無視します。

      • -mapname1systemname1pguser1

      • -mapname1systemname2pguser2

  • standby/_cluster ：このセクションが定義されている場合、スタンバイクラスターをブートストラップします。

    • host ：リモートノードのアドレス

    • port ：リモートノードのポート

    • primary/_slot/_name ：レプリケーションに使用するリモートノード上のスロット。このパラメーターはオプショナル、デフォルト値はインスタンス名から派生します（ファンクション`slot_name_from_member_name`を参照）。

    • create/_replica/_methods ：リモートプライマリからスタンバイリーダーをブートストラップするために使用できるメソッドの順序付けられたリスト。 create/_replica/_methods で定義されたリストとは異なる場合があります

    • restore/_command ：リモートプライマリからスタンバイクラスター内のノードにWALレコードを復元するコマンドは、 restore/_command で定義されたリストと異なる場合があります

    • archive/_cleanup/_command ：スタンバイリーダーのクリーンアップコマンド

    • recovery/_min/_apply/_delay ：スタンバイリーダーにWALレコードを実際に適用するまで待機する時間

  • slots ：永続的なレプリケーションスロットを定義します。これらのスロットは、スイッチオーバー/フェールオーバー中に保持されます。存在しないパーマネントスロットはPatroniが作成します。物理スロットは、現在のプライマリでのみ維持されます。論理スロットは、再起動に伴いプライマリからスタンバイにコピーされ、その後、それらの位置は slots 秒ごとに進められます（必要な場合）。 libpq 接続を介して実行され、巻き戻しまたはスーパーユーザーの資格情報を使用して実行される論理スロットファイルのコピー（ slots セクションを参照）。レプリカの論理スロット位置が以前のプライマリよりも少し遅れる可能性は常にあります。そのため、フェールオーバー後に2回目に一部のメッセージを受信できるようにアプリケーションを準備する必要があります。そうする最も簡単な方法- confirmed_flush_lsn を追跡します。永続的な論理レプリケーションスロットを有効にするには slots を設定する必要があり、 hot_standby_feedback も自動的に有効になります。論理レプリケーションスロットのフェイルオーバーはPostgreSQL9.6以前では安全ではなく、PostgreSQLバージョン10にはいくつかの重要な機能がないため、この機能はPostgreSQL11以降でのみ動作します。

    • my/_slot/_name ：永続的なレプリケーションスロットの名前。パーマネントスロットの名前が現在のリーダーの名前と一致する場合、作成されません。Patroniは、この構成に追加された永続的なスロット名が、Patroniがメンバー用に自動的に作成するものと一致するかどうかをチェックしないことに注意してください。これらの名前が追加された場合、パトローニは、メンバーが応答しなくなった場合でも、作成されたスロットが削除されないことを保証します。通常、パトローニはスロットを削除します。これは、既存のメンバーを新しいPatroniクラスターにインポートする場合などのいくつかの状況では役立ちますが（詳細は my/_slot/_name を参照）、名前のこれらの衝突はDCSで持続されないことにオペレーターは注意する必要があります。Patroniの正常な機能。

      • type ：スロットタイプ。 physical または logical の可能性があります。スロットが論理的な場合は、 database および plugin を追加で定義する必要があります。

      • database ：論理スロットを作成するデータベース名。

      • plugin ：論理スロットのプラグイン名。

  • ignore/_slots :Patroniが一致するスロットを無視する必要があるレプリケーションスロットプロパティのセットのリスト。この構成/機能/など。一部のレプリケーションスロットがPatroniの外部で管理されている場合に役立ちます。一致するプロパティのサブセットにより、スロットが無視されます。

    • name :レプリケーションスロットの名前。

    • type ：スロットタイプ。 physical または logical になります。スロットが論理的な場合は、 database および/または plugin を追加で定義できます。

    • database ：データベース名（ logical スロットと一致する場合）。

    • plugin ：論理デコードプラグイン（ logical スロットと一致する場合）。

注： slots はハッシュマップであり、 slots は配列です。例：

slots:
  permanent_logical_slot_name:
    type: logical
    database: my_db
    plugin: test_decoding
  permanent_physical_slot_name:
    type: physical
  ...
ignore_slots:
  - name: ignored_logical_slot_name
    type: logical
    database: my_db
    plugin: test_decoding
  - name: ignored_physical_slot_name
    type: physical
  ...