Ctrl+K

Logical standby nodes

Logical standby nodes#

PGDでは、オフロードノード、読み取り専用ノード、受信専用ノード、または論理リードレプリカとしても知られる ロジカルスタンバイノード を作成できます。マスターノードには、0、1つ、またはそれ以上のロジカルスタンバイノードを持つことができます。

注釈

論理スタンバイノードは、データセンター間のネットワークトラフィックが懸念される環境で使用できます。それ以外の場合、ロケーションごとにより多くのデータノードを持つことが常に優先されます。

論理スタンバイノードは、継続的リカバリの状態で保持されるノードであり、必要になるまで常に更新されます。この動作は、パフォーマンスを向上させるために論理レプリケーションを使用しているときにPostgresフィジカルスタンバイが動作する方法に似ています。

bdr.join_node_group には、ノードをロジカルスタンバイノードとして途中参加したままにするpause_in_standby

オプションがあります。論理スタンバイノードは変更を受信しますが、ローカルで行われた変更を他のノードに送信しません。

後で、必要に応じて、 bdr.promote_node を使用します

ロジカルスタンバイを完全な通常の送信/受信ノードに移動します。

ロジカルスタンバイは、

bdr.join_node_group のDSNで定義された1つのソースノードからデータが送信されます。他のすべてのノードからの変更はこの1つのソースノードから受信され、マルチプルのサイト間の帯域幅が最小化されます。

高可用性を実現するために、ソースノードが停止した場合、1つのロジカルスタンバイをフルノードに昇格させ、シングルマスター操作と同様のフェールオーバー操作でソースを置き換えることができます。複数のロジカルスタンバイノードが存在する場合、他のノードは新しいマスターをフォローできないため、この手法の有効性は1つのロジカルスタンバイに制限されます。

既存のPGDノードから新しいスタンバイが作成される場合、グループスロットが最後に進められてから少なくとも16MBのLSNが経過するまで、操作に必要なレプリケーションスロットは新しいスタンバイに同期されません。極端な場合、これには、スロットがストリーミングレプリカで同期または作成される前に、完全な16 MBが必要になる場合があります。この間隔でフェールオーバーまたはスイッチオーバーが発生した場合、グループスロットおよびその他の依存スロットがまだ存在していないため、ストリーミングスタンバイをPGDノードに代わって昇格させることはできません。

スタンバイのスロット同期プロセスは、上流のファンクションを呼び出すことによりこれを解決します。この機能は、WALスイッチを実行し、すべてのPGDピアノードに進行状況の更新を再生するように要求することにより、 EDB Postgres分散クラスター全体のグループスロットを移動します。この動作により、グループスロットが短期間で前進します。これにより、スタンバイが初期スロットの同期に必要な時間が削減され、必要に応じてより迅速なフェイルオーバーが可能になります。

PostgreSQLでは、スロットを昇格する前に、スタンバイでスロットの同期が完了することを確認することが重要です。ターゲットデータベースのスタンバイで次のクエリを実行して、スロットがアップストリームと同期していることを監視および確認できます。このクエリーがtrue を返すと、プロモーションを続行できます。

SELECT true FROM pg_catalog.pg_replication_slots WHERE
    slot_type = logical AND confirmed_flush_lsn IS NOT NULL;

WALスイッチを手動で実行し、すべてのPGDピアノードに進行状況の更新を再生するように要求することにより、PGDクラスター全体のスロット同期プロセスをナッジすることもできます。このアクティビティにより、グループスロットが短時間で前進し、スタンバイでのスロット同期アップアクティビティも高速化されます。このターゲットデータベース内の任意のPGDピアノードで次のクエリーを実行できます。

SELECT bdr.run_on_all_nodes(SELECT pg_catalog.pg_switch_wal());
SELECT bdr.run_on_all_nodes(SELECT bdr.request_replay_progress_update());

スタンバイでモニタリングクエリを使用して、これらのクエリがそのスタンバイでのスロットの同期の高速化に役立つことを確認します。

ロジカルスタンバイでは、書き込みトランザクションが許可されます。これにより、ロジカルスタンバイに追加のインデックス、データのより長い保持期間、中間作業テーブル、LISTEN/NOTIFY、一時テーブル、マテリアライズドビュー、およびその他の違いを持つことができるため、大きなメリットがあります。

プロモーション前にコミットするロジカルスタンバイにローカルに加えられた変更は、他のノードに送信されません。プロモーション後にコミットするすべてのトランザクションは以降に送信されます。ロジカルスタンバイへの書き込みを実行する場合、昇格する前にデータベースを静止するように注意してください。

ロジカルスタンバイノードにDDL変更を行う場合がありますが、それらはレプリケートされず、グローバルDDLロックを取得しようとしません。 DDLと同様に動作するPGDファンクションもレプリケートされません。

DDL replication filtering を参照してください。ロジカルスタンバイに互換性のないDDL変更を行った場合、データベースは

ダイバージェントノード です。現在、ダイバージェントノードのプロモーションはレプリケーションに失敗します。その結果、ロジカルスタンバイノードをスタンバイとして使用する場合は、ロジカルスタンバイノードに発散的な変更がないようにするか、発散ノードが昇格しないように計画します。