動的構成設定

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

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

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 同期フォロワーが異常な候補とみなされ、正常な非同期フォロワーにスワップされるまでに遅延する可能性のある最大バイト数。パトローニは、複数のフォロワーがいる場合に最大レプリカlsnを利用します。それ以外の場合、リーダーの現在のwal lsnを使用します。デフォルトは-1で、値が0以下に設定されている場合、Patroniは同期の不健康なフォロワーをスワップするアクションを実行しません。トランザクション量が多いときにPatroniが同期フォロワーを頻繁にスワップしないように、十分に高い値を設定してください。
max/_timelines/_history DCSに保持されるタイムライン履歴アイテムの最大数。デフォルト値0。0に設定すると、DCSに完全な履歴が保持されます。
primary/_start/_timeout フェールオーバーがトリガーされる前に、プライマリが障害から回復できる時間秒単位。デフォルトは300秒です。 0に設定すると、フェイルオーバーは可能であればクラッシュが検出された直後に実行されます。非同期レプリケーションを使用する場合、フェールオーバーによりトランザクションが失われる場合があります。プライマリ障害のワーストケースのフェイルオーバー時間は次のとおりです。primary/_start/_timeoutがゼロの場合を除き、loop/_wait +primary/_start/_timeout +loop/_wait 。その場合、それは単なるloop/_waitです。耐久性と可用性のトレードオフに応じて値を設定します。
primary/_stop/_timeout Postgresを停止するときにPatroniが待機できる秒数、synchronous_modeが有効になっている場合にのみ有効です。 > 0に設定され、synchronous_modeが有効になっている場合、primary/_stop/_timeoutで設定された値を超えてstop操作が実行されている場合、PatroniはSIGKILLをポストマスターに送信します。耐久性と可用性のトレードオフに応じて値を設定します。パラメーターが設定されていないか、<= 0に設定されている場合、primary/_stop/_timeoutは適用されません。
synchronous/_mode 同期レプリケーションモードをオンにします。可能な値 off 、 on 、 quorum 。このモードでは、リーダーが synchronous_standby_names の管理を行い、最後の既知のリーダーまたは同期レプリカの1つのみがリーダーレースに参加できます。同期モードでは、Patroniがトランザクションの耐久性を保証できない場合、書き込みの可用性を失いますが、正常にコミットされたトランザクションがフェールオーバー時に失われません。詳細については、 synchronous/_mode を参照してください。
synchronous/_mode/_strict 使用可能な同期レプリカがない場合に同期レプリケーションを無効にせず、プライマリへのすべてのクライアントの書き込みをブロックします。詳細については、 synchronous/_mode/_strict を参照してください。
synchronous/_node/_count synchronous_mode が有効になっている場合、このパラメーターはPatroniによって使用され、同期スタンバイインスタンスの正確な数を管理し、メンバーが参加および離脱するときにDCSの状態とPostgreSQLの synchronous_standby_names パラメーターを調整します。パラメーターが対象ノードの数より大きい値に設定されている場合、自動的に調整されます。デフォルトの 1 。
failsafe/_mode failsafe/_mode を有効にします。デフォルト`false`。
postgresql
- use/_pg/_rewind pg_rewindを使用するかどうか。デフォルト`false`。クラスターは data page checksums initdb の --data-checksums オプションで初期化する必要があるか、 wal_log_hints を on に設定する必要があることに注意してください。そうしないと、 pg_rewind は機能しないことに注意してください。
- use/_slots レプリケーションスロットを使用するかどうか。 PostgreSQL 9.4+では、デフォルト`true`に設定されます。
- recovery/_conf フォロワーの構成時にrecovery.confに書き込まれる追加の構成設定。 PostgreSQL 12にはrecovery.confはありませんが、Patroniは透過的に処理するため、このセクションを引き続き使用できます。
- parameters {max_connections: 100, wal_level: /"replica/", max_wal_senders: 10, wal_log_hints: /"on/"} 形式のPostgresの構成パラメーターGUC。これらの多くは、レプリケーションが機能するために必要です。
- pg/_hba pg_hba.conf を生成するためにPatroniが使用する行のリスト。 hba_file PostgreSQLパラメーターがデフォルト以外の値に設定されている場合、Patroniはこのパラメーターを無視します。
  - - host all all 0.0.0.0/0 md5
  - - host replication promoter 127.0.0.1/32 md5 レプリケーションには、このような行が必要です。
- pg/_ident pg_ident.conf を生成するためにPatroniが使用する行のリスト。 ident_file PostgreSQLパラメーターがデフォルト以外の値に設定されている場合、Patroniはこのパラメーターを無視します。
  - -mapname1 systemname1 pguser1
  - -mapname1 systemname2 pguser2
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 スタンバイリーダーのcleanupコマンド
- recovery/_min/_apply/_delay スタンバイリーダーにWALレコードを実際に適用するまでの待機時間
member_slots_ttl シャットダウン時のレプリカの物理レプリケーションスロットの保持時間。デフォルト値`30min`。古い動作を維持したい場合は、`0`に設定しますDCSからメンバーキーの有効期限が切れると、スロットはすぐに削除されます。この機能はPostgreSQL 11以降でのみ動作します。
slots 永続的なレプリケーションスロットを定義します。これらのスロットは、スイッチオーバー/フェイルオーバー中に保持されます。存在しない永久スロットはパトローニによって作成されます。 PostgreSQL 11以降では、すべてのノードで永続的な物理スロットが作成され、その位置は slots 秒ごとに進められます。 11より古いPostgreSQLバージョンの場合、11の永久物理レプリケーションスロットは、現在のプライマリでのみ維持されます。論理スロットは、再起動とともにプライマリからスタンバイにコピーされ、その後 slots 秒ごとに位置が進みました必要に応じて。論理スロットファイルのコピーは、 libpq 接続を介し、リワインドまたはスーパーユーザー資格情報を使用して実行されます slots セクションを参照してください。レプリカの論理スロット位置は以前のプライマリより少し後である可能性が常にあります。したがって、アプリケーションは、フェールオーバー後に2回目に一部のメッセージを受信できるように準備する必要があります。そのための最も簡単な方法-トラッキング confirmed_flush_lsn 。永久レプリケーションスロットを有効にするには、 slots を true に設定する必要があります。定義された永続的な論理レプリケーションスロットがある場合、Patroniは自動的に hot_standby_feedback を有効にします。 PostgreSQL 9.6以前では論理レプリケーションスロットのフェールオーバーは安全でなく、PostgreSQLバージョン10にはいくつかの重要な機能が欠けているため、この機能はPostgreSQL 11以降でのみ動作します。
- my/_slot/_name 永続的レプリケーションスロットの名前。永続的なスロット名が現在のノードの名前と一致する場合、このノードでは作成されません。 Patroniメンバーの名前と一致する名前の永続的な物理レプリケーションスロットを追加すると、Patroniは、対応するメンバーが応答しなくなった場合でも、作成されたスロットが削除されないことを保証します。通常はPatroniによってスロットが削除されます。これは、一時的な障害中にメンバーが使用するレプリケーションスロットを持続させたい場合、または既存のメンバーを新しいパトロニクラスター my/_slot/_name を参照してください。詳細については、オペレーターがこれらのPatroniの通常の機能に影響を与えるため、スロットが必要でなくなった場合、名前の衝突はDCSに持続されません。
  - type スロットタイプ。 physical または logical になります。スロットが論理的な場合、 database および plugin を追加して定義する必要があります。スロットが物理的なスロットの場合、オプションで cluster_type を定義できます。
  - database 論理スロットを作成するデータベース名。
  - plugin 論理スロットのプラグイン名。
  - cluster_type クラスターのタイプ primary または standby スロットはのみに作成されます。それ以外の場合、作成されないか、既存のスロットはドロップされます。
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
  ...

注 PostgreSQL v11以降を実行している場合、Patroniはリーダーになる可能性のあるすべてのノードで物理レプリケーションスロットを維持するため、レプリカノードは他のノードが必要とする可能性がある場合にWALセグメントを予約したままにします。ノードが存在せず、DCSのメンバーキーの有効期限が切れた場合、対応するレプリケーションスロットは member_slots_ttl デフォルト値`30min`の後にドロップされます。ニーズに基づいて、リテンションを増加または減少させることができます。または、クラスタートポロジが静的名前が変更されないノードの固定数の場合、ノードの名前に対応する名前で永続的な物理レプリケーションスロットを構成して、レプリカが一時的にダウンしているときにスロットの削除とWALファイルのリサイクルを回避できます。

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

警告

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

警告

スタンバイで nostream タグを設定すると、ノード自分自身とそのすべてのカスケードレプリカある場合は、永久論理レプリケーションスロットのコピーと同期が無効になります。