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