動的構成設定¶

動的構成はDCS(分散構成ストア)に保存され、すべてのクラスターノードに適用されます。

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

loop/_wait :ループがスリープする秒数。デフォルト値:10、可能な最小値:1
ttl :リーダーロックを取得するためのTTL(秒単位)。これは、自動フェイルオーバープロセスが開始されるまでの時間と考えてください。デフォルト値:30、可能な最小値:20
retry/_timeout :DCSおよびPostgreSQL操作の再試行のタイムアウト(秒単位)。これより短いDCSまたはネットワークの問題によって、パトローニがリーダーを降格させることはありません。デフォルト値:10、可能な最小値:3

警告

loop_wait 、 loop_wait 、または loop_wait の値を変更する場合は、次のルールに従う必要があります。

loop_wait + 2 * retry_timeout <= ttl

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/_start/_timeoutが0の場合は除きます。その場合は、単なるloop/_waitです。耐久性と可用性のトレードオフに応じて値を設定します。
primary/_stop/_timeout :Postgresを停止するときにPatroniが待機できる秒数。synchronous_modeが有効な場合にのみ有効です。>0に設定され、synchronous_modeが有効な場合、停止操作がPrimary/_stop/_timeoutで設定された値を超えて実行されている場合、Patroniはポストマスターに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はこのパラメータを無視します。
  - -すべてをホスト0.0.0.0/0md5
  - -ホストレプリケーションレプリケータ127.0.0.1/32md5 :レプリケーションには次のような行が必要です。
- pg/_ident :Patroniが pg_ident.conf を生成するために使用する行のリスト。 ident_file PostgreSQLパラメータがデフォルト以外の値に設定されている場合、Patroniはこのパラメータを無視します。
  - -マップ名1システム名1pguser1
  - -マップ名1システム名2pguser2
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 :永続的なレプリケーションスロットを定義します。これらのスロットは、スイッチオーバー/フェイルオーバー中に保持されます。存在しない永久スロットはパトローニによって作成されます。PostgreSQL11以降では、永続的な物理スロットがすべてのノードに作成され、その位置は slots 秒ごとに進められます。11よりも古いバージョンのPostgreSQLの場合、永続的な物理レプリケーションスロットは現在のプライマリでのみ維持されます。論理スロットは再起動によってプライマリからスタンバイにコピーされ、その後(必要に応じて) slots 秒ごとに位置が進みます。論理スロットファイルのコピーは、 libpq 接続経由で、rewindまたはスーパーユーザーの資格情報を使用して実行されます( slots セクションを参照)。レプリカ上の論理スロットの位置が以前のプライマリより少し遅れている可能性が常にあります。そのため、アプリケーションは、フェイルオーバー後の2回目に一部のメッセージを受信できるように準備する必要があります。これを行う最も簡単な方法は、 confirmed_flush_lsn を追跡することです。永久レプリケーションスロットを有効にするには、 slots を true に設定する必要があります。永続的な論理レプリケーションスロットが定義されている場合、Patroniは自動的に hot_standby_feedback を有効にします。PostgreSQL9.6以前では論理レプリケーションスロットのフェイルオーバーが安全でなく、PostgreSQLバージョン10にはいくつかの重要な機能が欠けているため、この機能はPostgreSQL11以降でのみ動作します。
- my/_slot/_name :永続レプリケーションスロットの名前。永続スロット名が現在のノードの名前と一致する場合、そのスロットはこのノードには作成されません。Patroniメンバーの名前と一致する名前の永続的な物理レプリケーションスロットを追加すると、Patroniは、対応するメンバーが応答しなくなった場合でも、作成されたスロットが削除されないようにします。この状況では、通常はPatroniによってスロットが削除されます。これは、一時的な障害時にメンバーが使用するレプリケーションスロットを維持したい場合や、既存のメンバーを新しいPatroniクラスターにインポートする場合(詳細については my/_slot/_name を参照)など、状況によっては便利ですが、オペレーターはこれらのことが発生することに注意する必要があります。名前の衝突は、スロットが不要になった場合、Patroniの通常の機能に影響を与えるため、DCSには保持されません。
  - 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
  ...

注:クラスタートポロジが静的(名前が変更されない固定数のノード)の場合は、レプリカが一時的に停止している間にWALファイルのリサイクルを回避するために、ノードの名前に対応する名前を使用して永続的な物理レプリケーションスロットを構成できます。

slots:
  node_name1:
    type: physical
  node_name2:
    type: physical
  node_name3:
    type: physical
  ...

警告

永続レプリケーションスロットは、 primary / standby_leader からレプリカノードにのみ同期されます。つまり、アプリケーションはリーダーノードからのみそれらを使用することになっています。これらをレプリカノードで使用すると、クラスター内の他のすべてのノードで pg_wal が無制限に増加します。このルールの例外は、Patroniメンバー名と一致する永続的な物理スロット(構成している場合)です。これらはノード間のレプリケーションに使用されるため、すべてのノード間で同期されます。