レプリケーションモード¶
PatroniはPostgreSQLストリーミングレプリケーションを使用します。ストリーミングレプリケーションの詳細については、 Postgres documentation _を参照してください。デフォルトでは、Patroniは非同期レプリケーション用にPostgreSQLを構成します。レプリケーションスキーマの選択は、ビジネスの考慮事項によって異なります。非同期レプリケーションと同期レプリケーションの両方、および他のHAソリューションを調査して、どのソリューションが最適であるかを判断します。
非同期モードの耐久性¶
非同期モードでは、クラスターは可用性を保証するために、コミットされたトランザクションの一部を失うことができます。プライマリサーバーに障害が発生するか、他の理由で使用できなくなると、Patroniは十分に正常なスタンバイをプライマリに自動的にプロモートします。そのスタンバイにレプリケートされていないトランザクションは、プライマリ上の/"フォークされたタイムライン"に残り、事実上回復不能です[1]_。
失われる可能性のあるトランザクションの量は、 maximum_lag_on_failover パラメーターを介して制御されます。プライマリトランザクションログの位置はリアルタイムでサンプリングされないため、実際には、フェールオーバーでの損失データの量は、ワーストケースになります。トランザクションログの maximum_lag_on_failover バイトと、最後の ttl 秒に書き込まれた量 loop_wait /2秒平均的な場合）。ただし、一般的な定常状態のレプリケーション遅延は1秒未満です。
デフォルトでは、リーダー選挙を実行するときに、パトローニはレプリカの現在のタイムラインを考慮しません。これは、場合によっては望ましくない動作である可能性があります。 check_timeline パラメーターの値を true に変更することにより、元のプライマリと同じタイムラインを持たないノードが新しいリーダーになるのを防ぐことができます。
PostgreSQL同期レプリケーション¶
PatroniではPostgresの synchronous replication _を使用できます。同期レプリケーションは、接続しているクライアントに成功して返す前に、書き込みがセカンダリに書き込まれることを確認することにより、クラスター全体の一貫性を保証します。同期レプリケーションのコスト書き込み時のスループットの低下。このスループットは、ネットワークパフォーマンスに完全に基づいています。
ホスト型データセンター環境AWS、Rackspace、または制御していないネットワークなどでは、同期レプリケーションにより書き込みパフォーマンスの変動が大幅に増加します。フォロワーがリーダーからアクセスできなくなると、リーダーは事実上読み取り専用になります。
単純な同期レプリケーションテストを有効にするには、YAML構成ファイルの parameters セクションに次の行を追加します。
synchronous_commit: "on"
synchronous_standby_names: "*"
PostgreSQL同期レプリケーションを使用する場合、少なくとも3つのPostgresデータノードを使用して、1つのホストに障害が発生した場合の書き込み可用性を保証します。
PostgreSQL同期レプリケーションを使用しても、すべての状況でトランザクション損失ゼロを保証するものではありません。プライマリと、現在同期レプリカとして機能しているセカンダリに同時に障害が発生すると、すべてのトランザクションが含まれていない可能性がある3番目のノードが昇格します。
同期モード¶
コミットされたトランザクションの損失が許容されないユースケースでは、Patroniの synchronous_mode をオンにすることができます。 synchronous_mode がオンになっている場合、Patroniは、スタンバイにクライアント[2]_に成功したコミットステータスを返した可能性のあるすべてのトランザクションが含まれていることが確実でない限り、スタンバイをプロモートしません。これは、一部のサーバーが利用可能な場合でも、システムは書き込みに利用できない場合があることを意味します。システム管理者は、トランザクション損失が発生した場合でも、手動フェイルオーバーコマンドを使用してスタンバイを昇格させることができます。
synchronous_mode をオンにしても、すべての状況でのコミットのマルチノードの耐久性は保証されません。使用可能な適切なスタンバイがない場合、プライマリサーバーは書き込みを受け入れますが、レプリケーションは保証しません。このモードでプライマリに障害が発生すると、スタンバイは昇格しません。プライマリであったホストが復帰すると、システム管理者が手動フェイルオーバーを実行しない限り、自動的に昇格します。この動作により、2ノードクラスターで同期モードを使用できるようになります。
synchronous_mode がオンで、スタンバイがクラッシュすると、パトロニの次の反復が実行され、プライマリをスタンドアロンモードに切り替えるまで、コミットがブロックされます書き込みの最悪の場合の遅延は ttl 秒、平均的な場合は loop_wait /2秒。スタンバイを手動でシャットダウンまたは再起動しても、コミットサービスの中断は発生しません。スタンバイは、PostgreSQLのシャットダウンが開始される前に、同期スタンバイ業務から自分自身を解放するようにプライマリに信号を送信します。
各書き込みが少なくとも2つのノードに永続的に保存されることを保証する必要がある場合は、 synchronous_mode に加えて synchronous_mode_strict を有効にします。このパラメーターは、使用可能な同期スタンバイ候補がない場合、Patroniがプライマリで同期レプリケーションをオフにしないようにします。欠点として、プライマリはPostgresトランザクションが明示的に synchronous_mode をオフにしていない限り書き込みに利用できず、少なくとも1つの同期レプリカが登場するまで、すべてのクライアントの書き込み要求をブロックします。
nosync タグをtrueに設定することにより、スタンバイが同期スタンバイにならないようにできます。これは、遅いネットワーク接続の背後にあり、同期スタンバイになるとパフォーマンスの低下を引き起こすスタンバイに設定することをお勧めします。タグ nostream をtrueに設定しても、同じ効果があります。
同期モードは、PatroniRESTインターフェイスを介してオンおよびオフにできます。手順については、 dynamic configuration を参照してください。
注PostgreSQLで同期レプリケーションが実装される方法のため、 synchronous_mode_strict を使用する場合でもトランザクションが失われる可能性があります。レプリケーションの確認を待機しているときにPostgreSQLバックエンドがキャンセルされると、クライアントのタイムアウトまたはバックエンドの障害によるパケットキャンセルの結果、トランザクションの変更が他のバックエンドに表示されるようになります。このような変更はまだ複製されていないため、スタンバイプロモーションの場合に失われる可能性があります。
同期レプリケーションファクター¶
パラメーター synchronous_node_count は、Patroniが同期スタンバイデータベースの数を管理するために使用されます。デフォルトでは1に設定されています。 synchronous_mode がoffに設定されている場合、効果はありません。有効にすると、Patroniはパラメーター synchronous_node_count に基づいて同期スタンバイデータベースの正確な数を管理し、メンバーが参加および離脱するときにDCSおよびsynchronous_standby_namesの状態を調整します。
同期モードの実装¶
同期モードの場合、Patroniは、最新のプライマリおよび現在の同期スタンバイデータベースを含むDCSの同期状態を維持します。この状態は、次の不変条件を保証するために厳密な順序制約で更新されます。
ノードは、書き込みトランザクションを受け入れることができるときは常に、最新のリーダーとしてマークされる必要があります。Patroniがクラッシュするか、PostgreSQLがシャットダウンしていない場合、このインバリアントの違反が発生する可能性があります。
ノードは同期スタンバイとして公開されている限り、PostgreSQLで同期スタンバイとして設定する必要があります。
リーダーまたは現在の同期スタンバイではないノードは、自分自身を自動的に昇格させることはできません。
Patroniは、 synchronous_standby_names への synchronous_node_count パラメーターに基づいて、1つ以上の同期スタンバイノードのみを割り当てます。
HAループ反復ごとに、Patroniは同期スタンバイノードの選択を再評価します。同期スタンバイノードの現在のリストが接続され、同期ステータスの削除を要求していない場合、選択されたままです。それ以外の場合、レプリケーションで最も進んでいる同期に使用可能なクラスターメンバーが選択されます。