Node management

BDRグループのメンバーである各データベースは、独自のノードで表す必要があります。ノードは、 BDRグループ内のデータベースの一意の識別子です。

現在、各ノードは1つのノードグループのメンバーになれます。 (これは後のリリースで拡張される可能性があります。)各ノードは1つ以上のレプリケーションセットをサブスクライブして、レプリケーションをきめ細かく制御できます。

BDRグループには0個以上のサブグループが含まれる場合があり、さまざまなアーキテクチャを作成できます。

BDRグループの作成と参加

BDRの場合、すべてのノードは他のすべてのノードに接続する必要があります。構成を簡単にするために、新しいノードが参加すると、それに接続するように既存のすべてのノードが構成されます。このため、作成された最初のBDRノードを含むすべてのノードは、他のノードが接続に使用できる

PostgreSQL connection string

（データソース名（DSN）とも呼ばれます）を認識する必要があります。両方の形式の接続文字列がサポートされています。したがって、 host=myhost port=5432 dbname=mydb などのキー値形式、または postgresql://myhost:5432/mydb などのURI形式を使用できます。

SQLファンクション bdr.create_node_group() は、ローカルノードからBDRグループを作成します。これにより、そのノードでBDRがアクティブになり、他のノードがその時点で1つのノードのみで構成されるBDRグループに参加できるようになります。作成時に、他のノードがこのノードに接続するために使用する接続文字列を指定する必要があります。

ノードグループが作成されると、以降のすべてのノードは bdr.join_node_group() ファンクションを使用してBDRグループに参加できます。

または、コマンドラインユーティリティ bdr_init_physical を使用して、既存のノードのpg_basebackup （またはフィジカルスタンバイ）を使用して新しいノードを作成します。 pg_basebackup を使用している場合、 bdr_init_physical ユーティリティはオプションでターゲットデータベースのみのベースバックアップを指定できます。以前の動作は、データベースクラスター全体をバックアップすることでした。このユーティリティを使用すると、不要なデータベースが除外されるため、アクティビティがより速く完了し、使用する領域が少なくなります。ターゲットデータベースのみを指定した場合、除外されたデータベースは新しいノードでクリーンアップされて削除されます。

新しいBDRノードが既存のBDRグループに参加する場合、またはノードがアップストリームピアにサブスクライブする場合、レプリケーションを開始する前に、システムは既存のデータをピアノードからローカルノードにコピーする必要があります。このコピーは、ローカルデータとリモートデータが最初は同じになるように注意深く調整する必要があります。自分で pg_dump を使用するだけでは不十分です。 BDR拡張機能は、この初期コピーを作成するための組み込み機能を提供します。

参加プロセス中に、 BDR拡張機能は、指定されたソースノードを基礎として使用して既存のデータを同期し、 BDRグループのメッシュトポロジで自分自身を確立するために必要なすべてのメタデータ情報を作成します。この初期コピー中にソースと新しいノード間の接続が切断された場合、参加プロセスを最初からやり直します。

クラスターに参加するノードには、 BDRグループのデータベースに既に存在するスキーマまたはデータを含めないでください。 BDR拡張子を除き、新しく参加するデータベースは空にすることをお勧めします。ただし、必要なすべてのデータベースユーザーとロールが作成されていることが重要です。

オプションで、 bdr.join_node_group() ファンクションのsynchronize_structure パラメータを使用してスキーマの同期をスキップできます。この場合、スキーマは新しく参加するノードに既に存在している必要があります。

参加するソースノードとして、接続が最適な（最も近い）ソースノードを選択することをお勧めします。これにより、結合が完了するまでに必要な時間が短縮されます。

Raftコンセンサスアルゴリズムを使用して参加手順を調整します。これには、ほとんどの既存のノードがオンラインで到達可能である必要があります。

論理結合プロシージャ（ bdr.join_node_group() ファンクションを使用する）は、 COPY 操作を実行してデータ同期を実行し、有効になっている場合はマルチプルのライター（並列適用）を使用します。

ノード参加は、参加にかかる時間の大部分を他のノード参加と同時に実行できます。ただし、一度に1つの通常ノードのみがPROMOTEまたはPROMOTINGの状態になります。これは、他のすべてのノードが稼働している場合、通常はかなり短くなります。それ以外の場合、結合はこの段階でシリアル化されます。サブスクライバー専用ノードはこのルールの例外であり、同時に PROMOTE 状態と PROMOTING 状態になる可能性があるため、参加プロセスは完全に同時です。

参加プロセスはソースとして1つのノードのみを使用するため、ノードの過半数が利用可能な場合に実行できます。これにより、論理結合の実行が複雑になる可能性があります。論理結合中に、ソースノードからコピーされた行のコミットタイムスタンプは、ソースノードの最新のコミットタイムスタンプに設定されます。これより前のコミットタイムスタンプを持つノードでコミットされた変更（ノードがダウンしているか、大幅な遅延があるため）は、他のノードからの変更と競合する可能性があります。この場合、新しく参加したノードは他のノードとは異なる方法で解決される可能性があり、発散が発生します。その結果、ノード間に重大なレプリケーションラグが存在する場合は、ノード参加を実行しないことをお勧めします。これが必要な場合は、新しく参加したノードでLiveCompareを実行して、すべてのノードが利用可能になって追いついたらデータの相違を修正します。

キャッシュルックアップの失敗が原因で、ソースノードで同時DDLアクティビティがある場合、 pg_dump が失敗する場合があります。 bdr.join_node_group() は内部でpg_dump を使用するため、ソースノードに同時のDDLアクティビティがある場合に失敗する場合があります。その場合、結合を再試行すると機能します。

異種クラスターへの参加

BDR 4.0ノードは、特定の最小メンテナンスリリース（3.7.6など）または3.7と4.0ノードの混合で3.7.xを実行しているEDB Postgres分散クラスターに参加できます。この手順は、 BDRメジャーバージョンだけでなく、基になるPostgreSQLメジャーバージョンもアップグレードする場合に役立ちます。これを実現するには、PostgreSQL 12または13で実行されている3.7ノードをPostgreSQL 11で3.6.xを実行しているEDB Postgres分散クラスターに参加します。 新しいノードは、既存のクラスター内のすべてのノードと同じPostgreSQLメジャーリリースで実行することもできます。

BDRは、一部のノードが1つのPostgreSQLメジャーリリースで3.6を実行していて、他のノードが別のPostgreSQLメジャーリリースで3.7を実行している場合でも、レプリケーションがすべての方向で正しく動作することを保証します。ただし、十分な数の新しいノードがクラスターに参加したら、古いノードを分割することにより、クラスターをすばやく同種の状態にすることをお勧めします。古いバージョンで使用できない可能性のあるDDLを実行しないでください。

別のPostgreSQLメジャーリリースに参加するノードはbdr_init_physical で取得した物理バックアップを使用できず、ノードは論理結合方法を使用して参加する必要があります。これが必要なのは、PostgreSQLのメジャーリリースが互いにディスク上で互換性がないためです。

3.7ノードが3.6ノードをソースとして使用してクラスターに参加すると、競合解決などの特定の構成がソースノードからコピーされません。ノードは、クラスターに参加した後に構成する必要があります。

接続DSNとSSL（TLS）

ノードはlibpq を使用して接続するため、ノードのDSNは単なるlibpq 接続文字列です。そのため、SSL用のものを含む、許可されたlibpq 接続パラメーターを含めることができます。 DSNは、指定されたノードに接続するクライアントからの接続文字列として機能する必要があります。クライアント証明書を使用するこのようなパラメーターのセットの例は次のとおりです。

sslmode=verify-full sslcert=bdr_client.crt sslkey=bdr_client.key
sslrootcert=root.crt

このセットアップでは、ファイル bdr_client.crt 、bdr_client.key 、およびroot.crt は、適切な権限を持つ各ノードのデータディレクトリに存在する必要があります。 verify-full モードの場合、サーバーのSSL証明書がチェックされ、 root.crt 認証局で直接または間接的に署名されていること、および接続で使用されるホスト名またはアドレスが証明書の内容と一致することが確認されます。名前の場合、これはサブジェクトの別名と一致します。証明書にそのような名前がない場合は、サブジェクトのコモンネーム（CN）フィールドと一致します。 Postgresは現在IPアドレスのサブジェクトの別名をサポートしていないため、名前ではなくアドレスで接続が行われる場合、 CNフィールドと一致する必要があります。

クライアント証明書のCNは、 BDR接続を行うユーザーの名前である必要があります。これは通常、ユーザーpostgresです。各ノードには、 pg_hba.conf ファイルでの接続を許可する一致する行が必要です。例：

hostssl all         postgres 10.1.2.3/24 cert
hostssl replication postgres 10.1.2.3/24 cert

別の設定では、クライアント証明書の代わりにSCRAM-SHA-256 パスワードを使用し、証明書が適切に署名されている限りサーバーIDを検証しません。ここでDSNパラメーターは次のとおりです。

sslmode=verify-ca sslrootcert=root.crt

対応するpg_hba.conf 行は次のとおりです。

hostssl all         postgres 10.1.2.3/24 scram-sha-256
hostssl replication postgres 10.1.2.3/24 scram-sha-256

このようなシナリオでは、postgresユーザーには正しいパスワードを含む.pgpass ファイルが必要です。

Witnessノード

クラスターに偶数個のノードがある場合、ネットワーク分割（またはネットワークパーティションとも呼ばれます）が発生した場合に関係を断ち切るのに役立つ追加のノードを作成すると役立つ場合があります。

追加のフルサイズのノードを作成する代わりに、監視ノードと呼ばれるマイクロノードを作成できます。これは、テーブルやデータを複製しないように意図的に設定された通常のBDRノードです。

ロジカルスタンバイノード

BDRを使用すると、オフロードノード、読み取り専用ノード、受信専用ノード、または論理読み取りレプリカとも呼ばれます。マスターノードは、ゼロ、1つ以上のロジカルスタンバイノードを持つことができます。

フィジカルスタンバイノードでは、ノードが完全に起動しないため、継続的リカバリモードが強制されます。 BDR同様のことができます。 bdr.join_node_group には、ノードをロジカルスタンバイノードとして途中で結合したままにするためのpause_in_standby オプションがあります。ロジカルスタンバイノードは変更を受信しますが、ローカルで行われた変更を他のノードに送信しません。

後で、必要に応じて bdr.promote_node() を使用して、ロジカルスタンバイを完全な通常の送信/受信ノードに移動します。

ロジカルスタンバイは、 bdr.join_node_group のDSNで定義された1つのソースノードによってデータが送信されます。他のすべてのノードからの変更はこの1つのソースノードから受信されるため、複数のサイト間の帯域幅が最小限に抑えられます。

高可用性には複数のオプションがあります。

  • ソースノードが停止した場合、1つのフィジカルスタンバイをマスターに昇格できます。この場合、新しいマスターは、任意またはすべてのロジカルスタンバイノードに電力を供給し続けることができます。

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

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

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

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

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

WALスイッチを手動で実行し、すべてのBDRピアノードに進行状況の更新を再生するように要求することにより、 BDRクラスター全体でスロット同期プロセスを微調整することもできます。このアクティビティにより、グループスロットが短時間で進み、スタンバイでのスロット同期アクティビティが早められます。このために、ターゲットデータベース内のBDRピアノードで次のクエリを実行できます。

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

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

ロジカルスタンバイノードは、必要に応じてフィジカルスタンバイノードを使用して保護できるため、 Master->LogicalStandby->PhysicalStandby。 LogicalStandbyからLogicalStandbyにカスケードすることはできません。

ロジカルスタンバイでは書き込みトランザクションが許可されるため、フィジカルスタンバイの制限は適用されません。これを使用すると、ロジカルスタンバイに追加のインデックス、データ、中間作業表、LISTEN/NOTIFY、一時テーブル、マテリアライズドビューなどの違いを設定できるため、大きなメリットがあります。

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

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

DMLおよびDDLレプリケーション を参照してください。ロジカルスタンバイに互換性のないDDL変更を加えた場合、データベースはダイバージェントノードです。ダイバージェントノードを昇格すると、現在レプリケーションが失敗します。その結果、ロジカルスタンバイノードをスタンバイとして使用する場合は、そのノードに変更が加えられないようにするか、または分散ノードが昇格しないようにしてください。

フィジカルスタンバイノード

BDRでは、従来のフィジカルスタンバイフェールオーバーノードを作成することもできます。これらは、一般的に、短い昇格手順の後にクラスター内のBDRノードを直接置き換えることを目的としています。標準のPostgresクラスターと同様に、ノードはこれらの物理レプリカをいくつでも持つことができます。

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

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

  • スタンバイには以下があります。- recovery.conf （PostgreSQL <12の場合、これらの設定はpostgres.conf にあります）： - プライマリを指すprimary_conninfo ：- shared_preload_libraries = 'bdr' 、リストには他のプラグインもありますが、 pglogicalを含めないでください - hot_standby = on - hot_standby_feedback = on

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

BDRノードの動作中のフィジカルスタンバイを生成するにはこれで十分ですが、いくつかの追加の問題に対処する必要があります。

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

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

フィジカルスタンバイノードが最新の状態であり、昇格できるようにする保護メカニズム（bdr.standby_slot_names の構成）は、 BDRグループの全体的なレプリケーション遅延に影響します。これは、フィジカルスタンバイノードが最新の場合にのみグループレプリケーションが発生するためです。

これらの理由から、通常、フィジカルスタンバイノードではなく、ロジカルスタンバイノードまたはサブスクライブ専用グループを使用することをお勧めします。比較すると、どちらも操作特性が優れています。

すべてのノードでグループスロットが（可能な限り）拡張されていることを手動で確認できます。これにより、次のSQL構文を使用して、フィジカルスタンバイでのBDR関連のレプリケーションスロットの作成が促進されます。

SELECT bdr.move_group_slot_all_nodes();

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

  • プライマリと同じIPアドレスまたはホスト名の制御を引き受けます。

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

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

bdr.standby_slot_names パラメーターにも注意してください。プライマリ -> フィジカルスタンバイの関係があるEDB Postgres分散クラスターで、またはサブスクライバー専用グループを使用する場合は、それを設定することが重要です。

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

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

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

  • スタンバイ時： - primary_conninfo にユニークなapplication_name を指定

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

synchronous_standby_names にフィジカルスタンバイと他のBDRノードを混在させることができます。 CAMOとEager All-Node Replicationは異なる同期メカニズムを使用し、同期レプリケーションでは機能しません。 synchronous_standby_names にCAMOパートナー（ CAMOを使用する場合）またはBDRノードをまったく含めないでください（ Eager All-Node Replicationを使用する場合）。代わりに、フィジカルスタンバイなどの非BDRノードのみを使用します。

サブグループ

グループには、0個以上のサブグループを含めることもできます。各サブグループは、トップレベルの親グループで特定の目的に割り当てることができます。 node_group_typeは、サブグループを作成するときにタイプを指定します。

購読者専用グループ

名前が示すように、このタイプのノードは、クラスター内の他のノードからのレプリケーションの変更のみをサブスクライブします。ただし、他のノードは subscriber-only ノードからレプリケーションの変更を受け取りません。これは、ロジカルスタンバイノードに多少似ています。ただし、ロジカルスタンバイとは対照的に、 subscriber-only ノードはクラスターに完全に参加しています。クラスター内の他のすべてのノードからレプリケーションの変更を受け取ることができるため、クラスター内のいずれかのノードが使用不可または分離されても影響を受けません。

subscriber-only ノードは完全に参加したBDRノードであるため、レプリケートされたすべてのDDLを受け取り、それらに動作します。また、Raftを使用して、クラスター内のすべてのノードにステータスを一貫して報告します。 subscriber-only ノードはRaftの投票権がないため、Raftリーダーになったり、リーダー選挙に参加したりできません。また、レプリケートされたDDLを受信しますが、 DDLまたはDMLロックの取得には参加しません。言い換えれば、現在ダウンしているsubscriber-only ノードは、DMLロックの取得を停止しません。

subscriber-only ノードは、 BDRツリートポロジの構成要素を形成します。このトポロジでは、少数の完全にアクティブなノードがすべての方向に変更を複製しています。多数のsubscriber-only ノードは変更のみを受け取りますが、クラスター内の他のノードに変更を送信することはありません。このトポロジーは、多数のノードによる接続の爆発を回避しますが、データの使用に使用できる非常に多数のleaf ノードを提供します。

subscriber-only ノードを利用するには、最初にタイプ subscriber-only のBDRグループを作成します。メンバーノードがレプリケーションの変更を受け取るグループのサブグループにします。サブグループを作成したら、 subscriber-only ノードになるすべてのノードはサブグループに参加する必要があります。 subscriber-only タイプのサブグループを複数作成でき、異なる親グループを持つことができます。

ノードがsubscriber-only サブグループに正常に参加すると、それはsubscriber-only ノードになり、親グループのレプリケーション変更の受信を開始します。 subscriber-only ノードで直接行われた変更は複製されません。

特定のタイプのサブグループを作成し、特定の親グループに属する方法については、 bdr.create_node_group() を参照してください。

注意事項

subscriber-only ノードはクラスター内のノードに変更をレプリケートしないため、ノードがクラスターから分離された場合、レプリケーションの変更を同期するソースとして機能できません。ただし、 subscriber-only ノードが既にクラスター内の他のノードにないpartedノードからレプリケーションの変更を受信して適用している場合、ノード間で不整合が発生します。

今のところ、 subscriber-only ノードよりも前に完全にアクティブなBDRノードが常に存在するように、 bdr.standby_slot_names とbdr.standby_slots_min_confirmed を設定することでこれを解決できます。 これは将来のリリースで改善される可能性があります。 subscriber-only ノードがレプリケーションの先頭になることを許可してからそれらを同期のレプリケーションソースとして使用するか、別の完全に結合されたノードが分離されたときに一貫性のない subscriber-only ノードをオプションで削除する方法を提供します。

デコードワーカー

BDR4は、データが送信されるノードの数に関係なく、1回のデコードを実行するデコードワーカープロセスを有効にするオプションを提供します。これにより、各BDRノードに新しいプロセス、WALデコーダーが導入されます。接続ごとに1つのWAL送信プロセスが存在しますが、これらのプロセスはデータの送受信のみを実行します。まとめると、これらの変更はより大きなBDRグループのCPUオーバーヘッドを削減し、WAL送信者プロセスが通信により多くの時間を費やすようになったため、レプリケーションスループットも向上します。

enable_wal_decoder はBDRグループごとのオプションであり、現在デフォルトで無効になっています。 bdr.alter_node_group_config() を使用して、 BDRグループのデコードワーカーを有効または無効にできます。

デコードワーカーが有効になっていると、 BDRは論理変更レコード（LCR）ファイルを保存して、デコードとすべてのサブスクライブノードがデータを受信したときの変更をバッファリングできます。 LCRファイルは、各ローカルノードのデータディレクトリのpg_logical ディレクトリに保存されます。レプリケーションの遅延が増加すると、LCRファイルの数とサイズが変化するため、これも監視する必要があります。 BDRノードで必要とされないLCRは定期的にクリーニングされます。 2つの連続するクリーンアップの間隔は、デフォルトの3分であるbdr.lcr_cleanup_interval によって制御されます。 bdr.lcr_cleanup_interval がゼロの場合、クリーンアップは無効です。

無効にすると、各ノードにサブスクライブする各ノードのWAL送信者プロセスによって論理デコードが実行されます。この場合、LCRファイルは書き込まれません。

BDRグループのデコードワーカーが有効になっている場合でも、次のGUCはノードごとのLCRの生成と使用を制御します。デフォルトでは、これらはfalse です。 LCRを作成して使用するには、 BDRグループのデコードワーカーを有効にし、これらのGUCをBDRグループの各ノードで true に設定します。

  • bdr.enable_wal_decoder — false を有効にすると、LCRを使用するすべてのWAL送信者が再起動してWALを直接使用します。 BDRグループ構成とともにtrue を使用すると、デコードワーカープロセスが開始されてLCRが生成され、WAL送信者はLCRを使用します。

  • bdr.receive_lcr —サブスクライブノードでtrue を使用する場合、パブリッシャーノードのWALセンダーにLCRを使用するように要求します。

ノート

現時点では、デコードワーカーは、実行されているノードに対応する変更をデコードします。ロジカルスタンバイには、 BDRグループ内のすべてのノードから単一のソースを介して変更が送信されます。したがって、ロジカルスタンバイを提供するWAL送信者は現在LCRを使用できません。

サブスクライバー専用ノードは、各ノードから変更を直接受信します。したがって、加入者専用ノードにサービスを提供するWAL送信者はLCRを使用できます。

LCRが生成されても、対応するWALはデコードワーカーが有効になっていない場合と同様に保持されます。将来的には、特に必要がない場合、LCRに対応するWALを削除できる可能性があります。

参考までに、LCRファイル名の最初の24文字はWALファイル名と似ています。現在名前の最初の8文字はすべて「0」です。将来的には、WALセグメントファイル名の最初の8文字に似たTimeLineIdを表すことが期待されています。次の16文字の名前は、WALストリームに対してLCRの変更を追跡するために使用されるWALセグメント番号に似ています。

ただし、論理変更は、それらが属するトランザクションのコミット順序に従って並べ替えられます。したがって、LCRセグメント内のそれらの配置は、WALセグメント内の対応するWALの配置と一致しません。

最後の16文字のセットは、LCRセグメントのサブセグメント番号を表します。各LCRファイルはサブセグメントに対応しています。 LCRファイルはバイナリで可変サイズです。 LCRファイルの最大サイズは、デフォルトの1GBであるbdr.max_lcr_segment_file_size で制御できます。

ノードの再起動とダウンしたノードの回復

BDRは、ノードの再起動またはノードの切断から回復するように設計されています。切断されたノードは、各ピアノードに再接続し、そのノードから欠落しているデータを複製することにより、グループに再参加します。

ノードが起動すると、各接続は bdr.node_slots.state = catchup を表示し始め、欠落したデータの複製を開始します。各ピアノードからの欠落データの量に応じて、サーバーのワークロードに応じて、時間の経過とともに増加する可能性があります。

各ノードの書き込みアクティビティの量が均一でない場合、より多くのデータを持つノードからのキャッチアップ期間は他のノードよりも大幅に長くなる可能性があります。最終的に、スロットの状態は bdr.node_slots.state = streaming に変わります。

数時間や数日など、長期間オフラインになっているノードは、さまざまな理由でリソースの問題を引き起こし始める可能性があります。次の問題を理解せずに、長期にわたる停止を計画しないでください。

各ノードは変更情報を保持するため（ピアノードごとに1つの レプリケーションスロットのクリーンアップ を使用）、一時的に到達できないノードへの変更を後で再生できます。ピアノードが無期限にオフラインのままである場合、この蓄積された変更情報により、最終的にノードでPostgreSQLトランザクションログ（pg_wal のWAL）が不足し、データベースサーバが次のようなエラーでシャットダウンする可能性があります。

PANIC: could not write to file "pg_wal/xlogtemp.559": No space left on device

または、他のディスク不足関連の症状を報告する場合があります。

さらに、オフラインノードのスロットもカタログxminを抑え、カタログテーブルのバキュームを防ぎます。

EDB Postgres Extended ServerおよびEDB Postgres Advanced Serverでは、オフラインノードもデータのフリーズを抑制して、競合解決データの損失を防ぎます（

管理者はノードの停止を監視し（ Monitoring を参照）、ノードに十分な空きディスク領域があることを確認する必要があります。ワークロードが予測可能な場合は、経時的に使用される領域を計算できる場合があり、重大な問題が発生するまでにノードがダウンする可能性がある時間を予測できます。

BDRによって作成されたレプリケーションスロットを手動で削除しないでください。これを行うと、クラスターが損傷し、

BDRによって作成されたレプリケーションスロット

で説明されているように、スロットを使用していたノードをクラスターから分離する必要があります。

ノードがオフラインの間、他のノードはオフラインノードから同じデータセットをまだ受信していない可能性があるため、これはノード間でわずかな相違として表示される場合があります。分割プロセスは、ノード間のこの不均衡を修正します。 （後のバージョンではこれを早く行うかもしれません。）

BDRによって作成されたレプリケーションスロット

BDRマスターノードでは、次のレプリケーションスロットがBDRによって作成されます。

  • bdr_<database name>_<group name> という名前の1つのグループスロット

  • N-1 ノードスロット、名前付けbdr_<database name>_<group name>_<node name> 、ここでNは、ダイレクトロジカルスタンバイを含むクラスター内のBDRノードの合計数です

警告

これらのスロットを削除しないでください。 BDRはそれらを作成および管理し、必要に応じて削除します。

一方、ソフトウェア用の適切なコマンドを使用して、 Barmanや論理レプリケーションなどのソフトウェアに必要なレプリケーションスロットを作成または削除できますBDR。他のソフトウェアが使用するスロット名を接頭辞bdr_ で始めないでください。

たとえば、3つのノード alpha 、beta 、およびgamma で構成されるクラスターでは、 BDRを使用してmydb データベースを複製し、 BDRグループはmygroup と呼ばれます。

  • ノードalpha には3つのスロットがあります。 - bdr_mydb_mygroup という名前の1つのグループスロット - bdr_mydb_mygroup_beta およびbdr_mydb_mygroup_gamma という名前の2つのノードスロット

  • ノードbeta には3つのスロットがあります。 - bdr_mydb_mygroup という名前の1つのグループスロット - bdr_mydb_mygroup_alpha およびbdr_mydb_mygroup_gamma という名前の2つのノードスロット

  • ノードgamma には3つのスロットがあります。 - bdr_mydb_mygroup という名前の1つのグループスロット - bdr_mydb_mygroup_alpha およびbdr_mydb_mygroup_beta という名前の2つのノードスロット

グループレプリケーションスロット

グループスロットは、このノードからの送信レプリケーションについて、主にBDRグループ内のノード（すべてのロジカルスタンバイを含む）が追いついた最も古い安全な位置を追跡するためにBDRによって使用される内部スロットです。

グループスロット名はファンクションbdr.local_group_slot_name() で与えられます。

グループスロットでは次のことができます。

  • 既存のすべてのノードを起動して実行せずに（ノードの大部分は稼働している必要がありますが）、新しいノードをBDRグループに参加させます。参加中にダウンしたノードが再度複製を開始した場合。

  • 一部のノードが分割されたノードに完全に追いついていない場合でも、一貫してクラスターからノードを分割します。

  • いくつかの競合を見逃さないように、フリーズポイントを保持します。

  • タイムスタンプベースのスナップショットの履歴スナップショットを保持します。

グループスロットは通常非アクティブであり、他のノードからのRaft進行状況メッセージに応答して定期的にのみ高速転送されます。

警告

グループスロットを削除しないでください。通常は非アクティブですが、 EDB Postgres分散クラスターの適切なオペレーションには依然として不可欠です。ドロップすると、一部またはすべての機能が動作しなくなったり、誤った結果が発生したりする可能性があります。

長い識別子のハッシュ

他のPostgreSQL識別子と同様に、レプリケーションスロットの名前は63バイト以下にする必要があります。 BDRは、結果のスロット名がその制限に対して長すぎる場合に、データベース名、 BDRグループ名、およびノードの名前を短縮することによりこれを処理します。識別子を短くするには、文字列の最後のセクションを文字列自分自身のハッシュに置き換えます。

たとえば、 group20xxxxxxxxxxxxx （長さ20バイト）というBDRグループを使用してdb20xxxxxxxxxxxxxxxx （長さ20バイト）という名前のデータベースを複製するクラスターを考えます。 3597186 、be9cbd0 、7f304a2 はそれぞれdb20xxxxxxxxxxxxxxxx 、group20xxxxxxxxxxxxx 、a30xxxxxxxxxxxxxxxxxxxxxxxxxx のハッシュであるため、ノードa30xxxxxxxxxxxxxxxxxxxxxxxxxxx （長さ30バイト）に関連付けられた論理レプリケーションスロットが呼び出されます。

bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2

BDRグループからのノードの削除

BDRは拡張されたノードの停止から回復するように設計されているため、ノードを完全に削除するかどうかをシステムに明示的に伝える必要があります。ノードを完全にシャットダウンし、他のノードに通知しないと、パフォーマンスが低下し、最終的にシステム全体が動作を停止します。

ノードの削除はパーティングとも呼ばれ、 bdr.part_node() 関数を使用して実行されます。ノードを削除するには、（ノードの作成中に渡された）ノード名を指定する必要があります。削除するノードを含む、 BDRグループ内のアクティブなノードからbdr.part_node() ファンクションを呼び出すことができます。

参加手順と同様に、別れはRaftコンセンサスを使用して行われ、動作するには大部分のノードがオンラインである必要があります。

分離プロセスはすべてのノードに影響します。ラフトリーダーはノード間の投票を管理して、どのノードが分離ノードからの最新データを持っているかを確認します。次に、残りのすべてのノードが最新のノードへのセカンダリの一時的な接続を確立して、不足しているデータをキャッチできるようにします。

別れたノードはまだBDRに認識されていますが、リソースを消費しません。別れたノードと同じ名前でノードが再度追加される場合があります。まれに、ファンクションbdr.drop_node() を使用して、partedノードのすべてのメタデータをクリアすることができます。

BDRのアンインストール

BDR拡張機能を削除すると、メタデータテーブルを含むノード内のすべてのBDRオブジェクトが削除されます。次のコマンドでこれを行うことができます。

DROP EXTENSION bdr;

データベースがBDR固有のオブジェクトに依存している場合、 BDR拡張機能を削除できません。例は次のとおりです。

  • SnowflakeId やgalloc などのBDR固有のシーケンスを使用したテーブル

  • CRDTデータ型を使用する列

  • 一部のBDRカタログテーブルに依存するビュー

BDR拡張機能を削除する前に、これらの依存関係を削除してください。たとえば、依存オブジェクトを削除するか、列タイプをBDR以外の同等のものに変更するか、シーケンスタイプをlocal に戻します。

警告

ノードがBDRノードグループから正常に分離された場合、またはグループの最後のノードである場合にのみ、 BDR拡張機能を削除できます。 BDRメタデータを削除すると、他のノードとの間のレプリケーションが中断されます。

警告

ローカルデータベース内のローカルBDRノードまたはBDR拡張機能を削除すると、既存のセッションがBDR固有のワークフローを実行しようとして失敗する場合があります。セッションを切断してからクライアントを再接続するか、インスタンスを再起動することにより、問題を解決できます。

bdr.drop_node() 関数もあります。この機能は、お別れに困ったときなど、緊急時にご利用ください。

BDRトポロジーのリスト

BDRグループのリスト

次の単純なクエリは、現在のノードがメンバーであるすべてのBDRノードグループをリストします。現在、1行のみを返します。

SELECT node_group_name
FROM bdr.local_node_summary;

より複雑なクエリを使用して、各ノードグループの構成を表示できます。

SELECT g.node_group_name
, ns.pub_repsets
, ns.sub_repsets
, g.node_group_default_repset     AS default_repset
, node_group_check_constraints    AS check_constraints
FROM bdr.local_node_summary ns
JOIN bdr.node_group g USING (node_group_name);

BDRグループ内のノードのリスト

次の例に示すように、特定のノードグループ（ mygroup など）内のすべてのノードのリストをbdr.node_summary ビューから抽出できます。

SELECT node_name         AS name
, node_seq_id            AS ord
, peer_state_name        AS current_state
, peer_target_state_name AS target_state
, interface_connstr      AS dsn
FROM bdr.node_summary
WHERE node_group_name = mygroup;

current_state またはtarget_state クエリ列に示されるように、ノードの読み取り専用状態は、 STANDBY として示されます。

ノードの状態のリスト

  • NONE ：ワーカーの起動時にノードの状態は設定解除され、すぐに現在の既知の状態に設定されると予想されます。

  • CREATED ：bdr.create_node() は実行されましたが、ノードはまだEDB Postgres分散クラスターのメンバーではありません。

  • JOIN_START ：bdr.join_node_group() は、ローカルノードを既存のEDB Postgres分散クラスターに参加させ始めます。

  • JOINING ：ノード参加が開始され、現在初期同期フェーズであり、ノードにスキーマとデータを作成しています。

  • CATCHUP ：初期同期フェーズが完了しました。これで、参加は、参加が開始されてから上流のピアノードで実行されたトランザクションを取得して適用する最後のステップになりました。

  • STANDBY ：ノードの参加は完了しましたが、変更のブロードキャストはまだ開始されていません。すべての参加はこの状態でしばらく時間がかかりますが、ロジカルスタンバイとして定義されている場合、ノードはこの状態を継続します。

  • PROMOTE ：ノードはロジカルスタンバイであり、ノードの状態をACTIVE に移動するためにbdr.promote_node を呼び出しました。これら2つのPROMOTE 状態は、1つのノードのみがSTANDBY よりも高く、ACTIVE よりも低い状態にあるという事実と一貫している必要があります。

  • PROMOTING ：ロジカルスタンバイからフルBDRノードへの昇格が進行中です。

  • ACTIVE ：ノードは完全なBDRノードであり、現在はACTIVE です。これは、最も一般的なノードのステータスです。

  • PART_START ：ノードはACTIVE またはSTANDBY で、bdr.part_node を呼び出してEDB Postgres分散クラスターからノードを削除しました。

  • PARTING ：ノードは他のノードから切断し、コンセンサスまたはレプリケーションでそれ以上の役割を果たしません。

  • PART_CATCHUP ：非分割ノードは、最近分割されたノードから欠落しているデータを同期します。

  • PARTED ：ノードの分割操作がすべてのノードで完了しました。

一度に1つのノードのみが、状態PROMOTEまたはPROMOTINGのいずれかになります。

ノード管理インターフェース

SQLインターフェースを使用して、ノードを動的に追加および削除できます。

bdr.create_node

この関数はノードを作成します。

概要

bdr.create_node(node_name text, local_dsn text)

パラメーター

  • node_name —新しいノードの名前。データベースごとに許可されるノードは1つだけです。有効なノード名は、小文字、数字、ハイフン、およびアンダースコアで構成されます。

  • local_dsn —ノードへの接続文字列。

注意事項

この関数は、関連付けられたパブリック接続文字列を使用してローカルノードのレコードを作成します。ローカルレコードは1つしか存在できないため、作成すると、関数は再度実行されるとエラーを報告します。

この関数はトランザクション関数です。ロールバックでき、それによって加えられた変更は現在のトランザクションで表示されます。

この関数は、トランザクションが終了するまで、新しく作成された bdr ノードのロックを保持します。

bdr.drop_node

ノードを削除します。

警告

この関数は、通常の使用を対象としていません。テクニカルサポートから指示された場合にのみ実行してください。

この関数は、指定されたノードのメタデータをローカルデータベースから削除します。ノードは次のいずれかです。

  • ローカルノード。この場合、リモートノードに関する情報を含むすべてのノードメタデータが削除されます。

  • リモートノード。その場合、その特定のノードのメタデータのみが削除されます。

概要

bdr.drop_node(node_name text, cascade boolean DEFAULT false, force boolean DEFAULT false)

パラメーター

  • node_name —既存のノードの名前。

  • cascade —非推奨、将来的に削除されます。

  • force —すべての健全性チェックを回避し、矛盾を引き起こす可能性があるにもかかわらず、指定されたBDRノードのすべてのメタデータを強制的に削除します。テクニカルサポートのみが、別れに関連する緊急事態に備えて強制ノードドロップを使用します。

注意事項

これを実行する前に、 bdr.part_node() を使用してノードを分割します。

この関数は、指定されたノードのメタデータをローカルデータベースから削除します。ノードはローカルノードにすることができます。その場合、リモートノードに関する情報を含むすべてのノードメタデータが削除されます。または、リモートノードにすることもできます。その場合、その特定のノードのメタデータのみが削除されます。

注釈

BDR4は、各ノードにsnowflakeidおよびtimehardシーケンスで使用する一意のシーケンス番号が割り当てられているため、一度に最大1024個のノードレコード（ACTIVEとPARTEDの両方）を持つことができます。 PARTED ノードは自動的にクリーンアップされません。これが問題になった場合、この機能を使用してこれらのレコードを削除できます。

bdr.create_node_group

この機能は、ローカルノードをグループの唯一のメンバーとするBDRグループを作成します。

概要

bdr.create_node_group(node_group_name text,
                      parent_group_name text DEFAULT NULL,
                      join_node_group boolean DEFAULT true,
                      node_group_type text DEFAULT NULL)

パラメーター

  • node_group_name —新しいBDRグループの名前。ノード名と同様に、有効なグループ名は、小文字、数字、およびアンダースコアのみで構成する必要があります。

  • parent_group_name —サブグループの親グループの名前。

  • join_node_group —このパラメーターは、ノードが作成するグループに参加するかどうかを判断するのに役立ちます。デフォルト値はtrue です。これは、ノードが参加したくないシャードグループを作成しているときに使用されます。 parent_group_name を指定した場合のみ、これはfalse になります。

  • node_group_type —有効な値は、NULL 、subscriber-only 、datanode 、read coordinator 、およびwrite coordinator です。 subscriber-onlytype is used to create a group of nodes that receive changes only from the fully joined nodes in the cluster, but they never send replication changes to other nodes. See  :ref:`Subscriber-only nodes <#subscriber-only-nodes>`   for more details. Datanodeimplies that the group represents a shard, whereas the other values imply that the group represents respective coordinators. Except subscriber-only, the other values are reserved for future use. NULL`は、通常の汎用ノードグループが作成されることを意味します。

注意事項

このファンクションは、ローカルノードで実行されているローカルコンセンサスワーカーにリクエストを渡します。

この関数はトランザクションではありません。グループの作成はバックグラウンドプロセスであるため、機能が終了すると、変更をロールバックできません。また、変更は現在のトランザクションにすぐに表示されない場合があります。 bdr.wait_for_join_completion を呼び出して、それらが完了するまで待つことができます。

グループの作成にはロックはありません。

bdr.alter_node_group_config

この機能は、既存のBDRグループの設定パラメーターを変更します。 NULL値（すべてのデフォルト）を持つオプションは変更されません。

概要

bdr.alter_node_group_config(node_group_name text,
                            insert_to_update boolean DEFAULT NULL,
                            update_to_insert boolean DEFAULT NULL,
                            ignore_redundant_updates boolean DEFAULT NULL,
                            check_full_tuple boolean DEFAULT NULL,
                            apply_delay interval DEFAULT NULL,
                            check_constraints boolean DEFAULT NULL,
                            num_writers int DEFAULT NULL,
                                          enable_wal_decoder boolean DEFAULT NULL,
                                          streaming_mode text DEFAULT NULL,
                            default_commit_scope text DEFAULT NULL)

パラメーター

  • node_group_name —既存のBDRグループの名前。ローカルノードはグループの一部である必要があります。

  • insert_to_update —下位互換性のために予約されています。

  • update_to_insert —下位互換性のために予約されています。 BDRのバージョン。代わりに bdr.alter_node_set_conflict_resolver を使用してください。

  • ignore_redundant_updates —下位互換性のために予約されています。

  • check_full_tuple —下位互換性のために予約されています。

  • apply_delay —下位互換性のために予約されています。

  • check_constraints —レプリケートされたデータを書き込むときに適用プロセスが制約をチェックするかどうか。このオプションは非推奨であり、 BDRの将来のバージョンでは無効化または削除されます。

  • num_writers —このノードグループをバッキングするサブスクリプションの並列ライターの数。 -1は、デフォルト（GUC bdr.writers_per_subscription で指定）が使用されることを意味します。有効な値は、-1または正の整数です。

  • enable_wal_decoder —デコードワーカープロセスを有効/無効にします。 streaming_mode が既に有効になっている場合、デコードワーカープロセスを有効にすることはできません。

  • streaming_mode —大規模なトランザクションのストリーミングを有効/無効にします。 off に設定すると、ストリーミングは無効になります。他の値に設定すると、大規模なトランザクションは進行中にデコードされ、変更がダウンストリームに送信されます。値がfile に設定されている場合、ストリーミングトランザクションの着信変更はファイルに保存され、トランザクションがアップストリームでコミットされた後にのみ適用されます。値がwriter に設定されている場合、着信変更はライターの1つに直接送信されます（使用可能な場合）。並列適用が無効になっている場合、またはライタがストリーミングトランザクションを自由に処理できない場合、変更はファイルに書き込まれ、トランザクションがコミットされた後に適用されます。値がauto に設定されている場合、 BDRはトランザクションプロパティと使用可能なリソースに応じて、file とwriter をインテリジェントに選択しようとします。 WALデコーダーが既に有効になっている場合、 streaming_mode を有効にすることはできません。

詳細については、 トランザクションストリーミング を参照してください。

  • default_commit_scope —デフォルトで使用するコミットスコープ。最初は local コミットスコープ。これは、トップレベルのノードグループにのみ適用されます。同じコミットスコープの異なるオリジングループに個々のルールを使用できます。詳細については、 オリジングループ を参照してください。

注意事項

このファンクションは、デフォルトを変更するリクエストをグループコンセンサスメカニズムに渡します。行われた変更は、コンセンサスメカニズムを使用してグローバルに複製されます。

この関数はトランザクションではありません。要求はバックグラウンドで処理されるため、関数呼び出しをロールバックすることはできません。また、変更は現在のトランザクションにすぐに表示されない場合があります。

この関数はロックを保持しません。

警告

この関数を使用して`apply_delay` 値を変更しても、その変更は既にグループのメンバーであるノードには適用されません。この値は通常テスト以外では使用されないため、この制限は実稼働での使用にはほとんど影響しません。

bdr.join_node_group

この機能は、ローカルノードを既存のBDRグループに参加させます。

概要

bdr.join_node_group (
    join_target_dsn text,
    node_group_name text DEFAULT NULL,
    pause_in_standby boolean DEFAULT false,
    wait_for_completion boolean DEFAULT true,
    synchronize_structure text DEFAULT all
)

パラメーター

  • join_target_dsn —ローカルノードを追加するBDRグループ内の既存の（ソース）ノードへの接続文字列を指定します。

  • node_group_name — BDRグループのオプションの名前。デフォルトはNULLで、ソースノードに存在する情報からグループ名を検出しようとします。

  • pause_in_standby —オプションで、ロジカルスタンバイノードとしてのみ参加するように参加プロセスに指示します。これは後でフルメンバーに昇格できます。

  • wait_for_completion —参加プロセスが完了するまで待ってから、戻ります。デフォルトはtrue です。

  • synchronize_structure —結合中に実行する構造（スキーマ）同期の種類を設定します。有効なオプションは、完全なデータベース構造を同期するall と、構造を同期しないnone です。ただし、データは同期されます。

wait_for_completion がfalse として指定されている場合、これは参加プロシージャが開始されるとすぐに戻る非同期呼び出しです。結合の進行状況は、ログとbdr.state_journal_details 情報ビューで確認するか、 bdr.join_node_group() が戻った後にbdr.wait_for_join_completion() 関数を呼び出すことで確認できます。

注意事項

このファンクションは、 join_target_dsn 接続文字列が指すノードを介してグループコンセンサスメカニズムに要求を渡します。行われた変更は、コンセンサスメカニズムによってグローバルに複製されます。

この関数はトランザクションではありません。参加プロセスはバックグラウンドで行われるため、ロールバックできません。 wait_for_completion がtrue に設定されている場合、または後でbdr.wait_for_join_completion を呼び出すことにより、変更はローカルトランザクションにのみ表示されます。

ノードは単一のグループのみに属することができるため、この関数は各ノードで1回のみ呼び出すことができます。

ノード参加はBDRグループにロックを保持しません。

bdr.promote_node

この機能は、ローカルロジカルスタンバイノードをBDRグループのフルメンバーに昇格させます。

概要

bdr.promote_node(wait_for_completion boolean DEFAULT true)

注意事項

このファンクションは、デフォルトを変更するリクエストをグループコンセンサスメカニズムに渡します。行われた変更は、コンセンサスメカニズムによってグローバルに複製されます。

この関数はトランザクションではありません。プロモーション プロセスはバックグラウンドで行われるため、ロールバックすることはできません。 wait_for_completion がtrue に設定されている場合、または後でbdr.wait_for_join_completion を呼び出すことにより、変更はローカルトランザクションにのみ表示されます。

プロモーションプロセスは、他のプロモーションに対してロックを保持します。このロックは他の bdr.promote_node 呼び出しをブロックしませんが、プロモーションのバックグラウンドプロセスが一度に複数のノードで進むのを防ぎます。

bdr.wait_for_join_completion

この関数は、ローカルノードの参加手続きが完了するのを待ちます。

概要

bdr.wait_for_join_completion(verbose_progress boolean DEFAULT false)

パラメーター

  • verbose_progress —オプションで、結合手順中に実行された個々の手順に関する情報を出力します。

注意事項

この関数は、ローカルノードのチェックの状態がbdr.create_node_group 、bdr.join_node_group 、またはbdr.promote_node で設定されたターゲットの状態に到達するまで待機します。

bdr.part_node

BDRグループからノードを削除（分割）しますが、ノードからデータは削除しません。

削除するノードを含む、 BDRグループ内のアクティブなノードから関数を呼び出すことができます。ただし、ノードが分離されると、クラスター内の他のノードを分離することはできません。

注釈

ローカルノードを分割する場合は、 wait_for_completion を`false` に設定する必要があります。それ以外の場合は、エラーを報告します。

警告

このアクションは永続的です。ノードへのレプリケーションを一時的に停止する場合は、 bdr.alter_subscription_disable() を参照してください。

概要

bdr.part_node (
    node_name text,
    wait_for_completion boolean DEFAULT true,
    force boolean DEFAULT false
)

パラメーター

  • node_name —分割する既存のノードの名前。

  • wait_for_completion — true の場合、ノードがクラスターから完全に分離されるまで、関数は戻りません。それ以外の場合、関数は分離手順を開始し、待機せずにすぐに戻ります。ローカルノードで実行する場合、またはforce を使用する場合は常にfalse に設定します。

  • force —ローカルノード上のノードを強制的に削除します。コンセンサスに到達できない場合、またはノード分割プロセスがスタックしている場合、これによりノードの状態がローカルに設定されます。

警告

force = true を使用すると、 BDRグループが一貫性のない状態のままになる可能性があります。他の方法でノードを削除できない障害から回復する場合にのみ使用してください。

注意事項

この関数は、指定されたノードを分割するための要求をグループコンセンサスメカニズムに渡します。行われた変更は、コンセンサスメカニズムによってグローバルに複製されます。別れのプロセスはバックグラウンドで行われ、元に戻すことはできません。 wait_for_completion がtrue に設定されている場合、分割プロセスによる変更はローカルトランザクションでのみ表示されます。

force をtrue に設定すると、コンセンサスが失敗すると、この関数はローカルノードでのみ指定されたノードの状態を設定します。このような場合、ファンクションはトランザクションであり（ファンクションはノードの状態を変更するため）、ロールバックできます。 force がtrue に設定された状態で既に分割中のノードで関数が呼び出された場合、指定されたノードをローカルで分割されて終了します。これは、クラスターでコンセンサスに到達できない場合(つまり、ノードの大部分がダウンしている場合)、または分割プロセスがスタックしている場合にのみ役立ちます。ただし、受信していた分離ノードが書き込みを行うと、分離プロセスに時間がかかる場合があることを考慮することが重要です。他のノードは、指定されたノードから欠落しているデータを再同期する必要があります。強制的に分離すると、この再同期が完全にスキップされ、他のノードが一貫性のない状態のままになる可能性があります。

分割プロセスにはロックがありません。

bdr.alter_node_interface

この関数は、指定されたノードの接続文字列（DSN ）を変更します。

概要

bdr.alter_node_interface(node_name text, interface_dsn text)

パラメーター

  • node_name —変更する既存のノードの名前。

  • interface_dsn —ノードの新しい接続文字列。

注意事項

この関数を実行し、ローカルノードでのみ変更を加えます。これは、通常、変更されるノードを含むBDRグループ内のすべてのノードで実行することを意味します。

このファンクションはトランザクションです。ロールバックでき、変更は現在のトランザクションで表示されます。

関数はローカルノードでロックを保持します。

bdr.alter_subscription_enable

この機能は、指定されたサブスクリプションまたはローカルBDRノードのすべてのサブスクリプションを有効にします。これは、レジュームサブスクリプションとも呼ばれます。サブスクリプションが既に有効になっている場合、エラーはスローされません。このオペレーションの影響を受けるサブスクリプションの数を返します。

概要

bdr.alter_subscription_enable(
    subscription_name name DEFAULT NULL,
    immediate boolean DEFAULT false
)

パラメーター

  • subscription_name —有効にするサブスクリプションの名前。 NULL（デフォルト）の場合、ローカルノード上のすべてのサブスクリプションが有効になります。

  • immediate —これは現在効果がありません。

注意事項

この関数はレプリケートされず、ローカルノードのサブスクリプション (特定のノードまたはすべてのノード) に影響します。

このファンクションはトランザクションです。ロールバックでき、現在のトランザクションでカタログの変更を確認できます。サブスクリプションワーカーは、トランザクションがコミットされた後、バックグラウンドプロセスによって開始されます。

bdr.alter_subscription_disable

この機能は、指定されたサブスクリプションまたはローカルBDRノードのすべてのサブスクリプションを無効にします。オプションで、無効になっているサブスクリプションに関連付けられているすべてのワーカーをすぐに停止することもできます。これは、サブスクリプションの一時停止とも呼ばれます。サブスクリプションが既に無効になっている場合、エラーはスローされません。このオペレーションの影響を受けるサブスクリプションの数を返します。

概要

bdr.alter_subscription_disable(
    subscription_name name DEFAULT NULL,
    immediate boolean DEFAULT false,
    fast boolean DEFAULT true
)

パラメーター

  • subscription_name —無効にするサブスクリプションの名前。 NULL（デフォルト）の場合、ローカルノード上のすべてのサブスクリプションが無効になります。

  • immediate —アクションをすぐに強制し、無効になっているサブスクリプションに関連付けられているすべてのワーカーを停止するために使用されます。このオプションがtrue の場合、トランザクションブロック内でこの関数を実行することはできません。

  • fast —この引数は、 immediate の動作に影響します。 true （デフォルト）に設定されている場合、現在の作業が完了するのを待たずに、無効になっているサブスクリプションに関連付けられたすべてのワーカーを停止します。

注意事項

この関数はレプリケートされず、ローカルノードのサブスクリプション (特定のサブスクリプションまたはすべてのサブスクリプション) に影響します。

このファンクションはトランザクションです。ロールバックでき、現在のトランザクションでカタログの変更を確認できます。ただし、サブスクリプションワーカーが停止するタイミングはimmediate の値に依存します。 true に設定すると、ワーカーはCOMMIT を待たずにstopを受け取ります。 fast 引数がtrue に設定されている場合、ワーカーの中断は現在の作業が完了するまで待機しません。

ノード管理コマンド

BDRは、既存のノードの物理コピー（pg_basebackup ）を使用してBDRグループにノードを追加したり、既存のノードのフィジカルスタンバイをBDRグループ内の新しいノードに変換したりするためのコマンドラインユーティリティも提供します。

bdr_init_physical

これは、PostgreSQLのbinディレクトリに追加される通常のコマンドです。

データディレクトリを指定する必要があります。このデータディレクトリが空の場合、 pg_basebackup -X stream を使用して、高速なブロックレベルのコピー操作を使用してディレクトリを埋めます。

指定されたデータディレクトリが空でない場合、これが新しいノードのベースとして使用されます。データディレクトリが既にフィジカルスタンバイノードとしてアクティブになっている場合は、Postgresを管理するbdr_init_physical を実行する前にスタンバイを停止する必要があります。最初は追いつきを待ってから、マスターノードに昇格してBDRグループに参加します。 --standby オプションを使用すると、既存のフィジカルスタンバイがロジカルスタンバイノードに変わります。これは、指定されたデータディレクトリの開始状態ではなく、新しいBDRノードの終了状態を参照します。

このコマンドは、データベースからすべてのPostgreSQLネイティブ論理レプリケーションサブスクリプションを削除します（または、 -S オプションが使用されている場合は無効にします）。

概要

bdr_init_physical [OPTION] ...

オプション

一般オプション

  • -D, --pgdata=DIRECTORY —新しいノードに使用するデータディレクトリ。空または存在しないディレクトリ、または pg_basebackup -X stream コマンドを使用して移入されたディレクトリのいずれかです。

  • -l, --log-file=FILE —ログにはFILEを使用します。デフォルトはbdr_init_physical_postgres.log です。

  • -n, --node-name=NAME —新しく作成されたノードの名前（必須）。

  • --replication-sets=SETS —使用する複製セット名のコンマ区切りリストの名前。指定しない場合、すべての複製セットが使用されます。

  • --standby —完全な送信/受信ノードではなく、ロジカルスタンバイ(受信専用ノード)を作成します。

  • --node-group-name —参加するグループ。デフォルトはソースノードと同じグループです。

  • -s, --stop —初期化が完了したら、サーバーを停止します。

  • -v —ログの詳細度を上げます。

  • -L —空/存在しないデータディレクトリ（-Dオプション）で使用する場合、選択的にpg_basebackupを実行します。これはEDB Postgres Extended Serverのみの機能です。

  • -S —論理レプリケーションサブスクリプションを削除する代わりに、無効にします。

接続オプション

  • -d, --remote-dsn=CONNSTR —リモートノードの接続文字列（必須）。

  • --local-dsn=CONNSTR —ローカルノードの接続文字列（必須）。

構成ファイルのオーバーライド

  • --hba-conf —新しいpg_hba.conf へのパス。

  • --postgresql-conf —新しいpostgresql.conf へのパス。

  • --postgresql-auto-conf —新しいpostgresql.auto.conf へのパス。

注意事項

コマンドで指定されたレプリケーションセット名は、ノードがBDRグループに参加する前にデータディレクトリに存在するデータには影響しません。これは、 bdr_init_physical が独自のベースバックアップを作成するか、既存のベースバックアップが新しいBDRノードにプロモートされるかに当てはまります。したがって、 --replication-sets オプションは、ノードがBDRノードグループに参加した後にパブリッシュおよびサブスクライブされたデータにのみ影響します。この動作は、bdr.join_node_group() を使用する場合など、論理結合で複製セットを使用する方法とは異なります。

オペレーターは、結合の完了後に不要なテーブルを切り捨てることができます。 bdr.tables カタログを参照して、レプリケーションセットのメンバーシップを判断し、サブスクライブしたレプリケーションセットのメンバーではないテーブルを特定します。次の理由から、テーブルは削除せずに切り捨てることを強くお勧めします。

DDLレプリケーションセットは必ずしも行（DML）レプリケーションセットと同じではないため、誤って他のノードのテーブルを削除する可能性があります。

  • 後でテーブルをレプリケーションセットに追加し、ノードのサブセットで削除した場合は、レプリケーションセットに追加する前に、 DDL競合を作成せずにそれらのノードでのみ再作成する必要があります。

レプリケートされないテーブルを切り捨てて、それらは存在しますが空のままにする方が簡単で安全です。 BDRの将来のバージョンでは、物理的結合用に選択されたレプリケーションセットの一部ではないテーブルが自動的に省略または削除される可能性があります。動作はここに文書化されています。