Physical standby nodes#

PGDを使用すると、従来のフィジカルスタンバイフェールオーバーノードを作成できます。これらは通常、短いプロモーション手順の後に、クラスター内のPGDノードを直接置き換えることを目的としています。標準のPostgresクラスターと同様に、ノードには任意の数のこれらの物理レプリカを持つことができます。

ただし、 PGDでのレプリケーションスロットおよびその他の機能要件を使用するため、これが適切に動作するには最小限の前提条件がいくつかあります。

  • PGDプライマリとスタンバイ間の接続は、物理レプリケーションスロットを介したストリーミングレプリケーションを使用します。

  • スタンバイには以下があります。 - recovery.conf PostgreSQL <12の場合、PostgreSQL 12+の場合、これらの設定はpostgres.conf にあります。 - primary_conninfo 、プライマリを指す - primary_slot_name 、このスタンバイのみで使用されるプライマリの物理レプリケーションスロットの名前付け - postgresql.conf : - shared_preload_libraries = 'bdr' 、リストには他のプラグインも含めることができますが、pglogicalは含めないでください - hot_standby = on - hot_standby_feedback = on

  • プライマリには以下があります。 - postgresql.conf - bdr.standby_slot_names は、スタンバイのprimary_slot_name に使用される物理レプリケーションスロットを指定します。

これは、 PGDノードの作業用フィジカルスタンバイを生成するには十分ですが、いくつかの追加の懸念事項に対処する必要があります。

スタンバイは、確立されると、 PGDグループスロットを含むプライマリの他のPGD関連レプリケーションスロットの初期コピーをトリガーするために十分な時間とWALトラフィックを必要とします。少なくとも、スタンバイのスロットはライブであり、 pg_replication_slots によって報告されたゼロ以外のconfirmed_flush_lsn を報告した場合にのみフェールオーバー後に生き残ることができます。

その結果、フェールオーバーが正常に機能すると仮定する前に、書き込みアクティビティの量が少ない、新しく初期化されたPGDクラスターのフィジカルスタンバイノードをチェックしてください。この予防措置を講じないと、スタンバイがPGDノードとして機能するために必要なレプリケーションスロットの不完全なサブセットを持つことになり、フェールオーバーが中止される可能性があります。

フィジカルスタンバイノードが最新の状態であり、昇格できることを保証する保護メカニズム

bdr.standby_slot_names による構成に従って、

PGDグループの全体的なレプリケーションレイテンシーに影響を与えます。これは、グループレプリケーションがフィジカルスタンバイノードが最新の場合にのみ発生するためです。

これらの理由から、一般的にはフィジカルスタンバイノードの代わりにロジカルスタンバイノードまたはサブスクライブ専用グループを使用することをお勧めします。どちらも比較して、より良い操作特性を持っています。

すべてのノードでグループスロットが可能な限り前進していることを手動で確認できます。これは、次のSQL構文を使用して、フィジカルスタンバイでのPGD関連のレプリケーションスロットの作成を早めるのに役立ちます。

SELECT bdr.move_group_slot_all_nodes();

フェールオーバーが発生すると、スタンバイは2つのアクションのいずれかを実行してプライマリを置き換える必要があります。

  • プライマリと同じIPアドレスまたはホスト名の制御を想定しています。

  • 他のすべてのPGDノードで bdr.alter_node_interface ファンクションを実行することにより、アドレスの変更をEDB Postgres分散クラスターに通知します。

これが完了すると、他のPGDノードは、新しく昇格したスタンバイ→プライマリノードとの通信を再確立します。レプリケーションスロットは定期的にのみ同期されるため、この新しいプライマリは、既存のPGDノードが予想するよりも低いLSNを反映する可能性があります。この場合、PGDは各遅延スロットを各PGDノードが使用した最後の場所に高速転送します。

bdr.alter_node_interface )パラメーターにも注意してください。プライマリ ->

フィジカルスタンバイの関係があるEDB Postgres分散クラスター、またはサブスクライバ専用グループを使用する場合、これを設定することが重要です。

PGDは、アウトバウンドレプリケーションで最も大きな遅延を示すクラスターノードの状態を常に反映するグループスロットを維持します。物理レプリカを追加すると、グループスロットの状態に影響を与える不参加ノードメンバーが存在することをPGDに通知する必要があります。

スタンバイは他のPGDノードと直接通信しないため、 standby_slot_names パラメーターは、グループスロットの必要に応じて名前付けスロットを考慮するようにPGDに通知します。設定すると、グループスロットが通常に進んでいる場合でも、スタンバイが遅延を示している場合、グループスロットは保持されます。

他の物理レプリカと同様に、このタイプのスタンバイも同期レプリカとして構成できます。これには次のものが必要です。

  • スタンバイ - primary_conninfo に一意のapplication_name を指定する

  • プライマリで - synchronous_commit を有効にする - synchronous_standby_names にスタンバイapplication_name を含める

synchronous_standby_names でフィジカルスタンバイと他のPGDノードを混合することが可能です。 CAMOおよびEager All-Node Replicationは、異なる同期メカニズムを使用し、同期レプリケーションでは動作しません。 CAMOまたはEager All-Node Replicationが使用される場合、 synchronous_standby_names にPGDノードが含まれていないことを確認します。代わりに、非PGDノードたとえば、フィジカルスタンバイのみを使用します。