Node Management

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

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

BDRグループには、0個以上のサブグループを含めることもでき、さまざまな異なるアーキテクチャを作成できます。

BDRグループの作成と参加

BDRの場合、すべてのノードに他のすべてのノードへの接続が必要です。構成を簡単にするために、新しいノードが参加すると、既存のすべてのノードが自動的に接続するように構成されます。このため、最初に作成されたBDRノードを含むすべてのノードは、他のノードが接続に使用する（「データソース名前」のDSNと呼ばれることもある）ことを知っている必要があります。接続文字列の両方の形式がサポートされています。そのため、host=myhost port=5432 dbname=mydbなどのkey-valueフォーマット、またはURIフォーマット：postgresql://myhost:5432/mydbのいずれかを使用できます。

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

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

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

!!! Warning * 一度に1つのノードのみがBDRノードグループに結合か、BDRノードグループから分離されます。進行中の別の結合またはパートオペレーションがある間に新しいノードが結合されている場合、結合が完了した後、新しいノードに一貫性のあるデータがない場合があります。

新しいBDRノードが既存のBDRグループに参加するか、ノードがアップストリーム同等なにサブスクライブされると、レプリケーションを開始する前に、システムは既存のデータを同等なからローカルノードにコピーする必要がありノード。このコピーは、ローカルデータとリモートデータが同一で始まるように慎重に調整する必要があります。 pg_dumpを自分で使用するだけでは不十分です。 BDRextensionは、この初期コピーを作成するためのビルトインファシリティを提供します。

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

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

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

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

結合プロシージャは、Raftコンセンサスアルゴリズムを使用して調整されます。これは、ほとんどの既存ノードがオンラインで到達可能である必要があります。

ロジカル結合プロシージャ（bdr.join_node_group()ファンクションを使用）は、COPY操作を行うデータ同期を実行し、それらが有効な場合はマルチプルのライターを使用します（並列適用）。

ノード結合は、結合にかかる時間の大半で、他のノード結合と同時に実行できます。通常はかなり短い状態であるPROMOTEまたはPROMOTINGのいずれかの状態にできるのは、一度に1つの通常のノードのみです。サブスクライバーのみのノードは、このルールの例外であり、PROMOTEおよびPROMOTING状態にも同時に存在できます。

結合プロセスはソースとして1つのノードのみを使用するため、ノードの大部分が使用可能な場合、ノードが停止しているときに実行できることに注意してください。これにより、ロジカル結合のコミット時にタイムスタンプさが生じる可能性がありロジカル。ソースノードは、ソースノードの最新のコミットタイムスタンプに設定されます。これより前のコミットタイムスタンプを持つノードでコミットされた変更は（ノードがダウンしているか、大幅な遅れがあるため）他のノードからの変更と競合する可能性があります。この場合、新しく結合されたノードは他のノードとは異なる方法で解決され、分岐が発生する可能性があります。そのため、ノード間に大きなレプリケーションラグが存在する場合はノード結合を実行しないことをお勧めしますが、これが必要な場合は、新しく結合したノードでLiveCompareを実行して、すべてのノードが利用可能になり追いついたらデータの相違を修正します。

キャッシュ検索の失敗により、ソースノードで同時DDLアクティビティがある場合、pg_dumpが失敗する場合があります。 bdr.join_node_group（）はpg_dumpを内部的に使用するため、ソースノードで同時DDLアクティビティがある場合、失敗する可能性があります。このような場合、結合の再試行が機能するはずです。

異種クラスターへの参加

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

一部のノードがPostgreSQLメジャーリリースで3.6を実行し、他のノードが別のPostgreSQLメジャーリリースで3.7を実行している場合でも、 BDRはレプリケーションがすべての方向で正しく機能することを保証します。ただし、十分な数の新しいノードがクラスターに参加したら、ユーザは古いノードを切り離すことで、クラスターを迅速に不均質な状態にすることをお勧めします。古いバージョンでは使用できないDDLを実行しないように注意する必要があります。逆の場合も同様です。

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

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

接続DSNとSSL（TLS）

ノードはlibpqを使用して接続するため、ノードのDSNは単純にlibpq接続文字列です。そのため、許可されたlibpq接続パラメーター（SSLの接続パラメーターを含む）を含めることができます。 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 CertificateAuthorityで直接または間接的に署名されます。接続で使用されるホスト名前またはアドレスが証明書の内容と一致すること。 名前の場合、これはSubjectAlternative Nameにマッチするか、証明書にそのような名前がない場合、SubjectのCommon Name（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

別の設定としては、clientcertificatesの代わりにSCRAM-SHA-256パスワードを使用し、証明書が適切に署名されている限りサーバーの身元を確認する必要はありません。ここで、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ファイルを必要とします。

監視ノード

クラスターのノード数が偶数のイベント、ネットワーク分割（またはネットワークパーティションとも呼ばれます）が発生した場合に追加のノードを作成して結び付けを解除すると便利な場合がありヘルプ。

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

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

BDRでは、「offloadnode」、「read-only ノード」、「receive-only ノード」または「ロジカル read レプリカ 」とも呼ばれる「ロジカルスタンバイノード」を作成できます。マスタノードには、0、1、またはより多くのロジカルスタンバイノード。

物理的スタンバイノードでは、ノードが完全に起動することはなく、継続的なリカバリモードのままになります。 BDR同様のことが可能です。 bdr.join_node_groupにはmakeオプションがあり、ノードをロジカルスタンバイノードとして中途半端にとどめます。論理スタンバイノードは変更を受信しますが、ローカルで行われた変更を他のノードに送信しません。

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

ロジカルスタンバイは、DSN inbdr.join_node_groupによって定義された1つのソースノードによってデータを送信されます。他のすべてのノードからの変更は、このonesourceノードから受信され、マルチプルのサイト間の帯域幅を最小化します。

高可用性にはマルチプルのオプションがあります。

  • ソースノードが停止した場合、1つの物理的スタンバイをマスタに昇格できます。 この場合、新しいマスタは、すべてまたはすべてのロジカルスタンバイノードにフィードを継続できます。

  • ソースノードの場合 死に、1つのロジカルスタンバイをノードに昇格させ、ソースを置き換えることができます シングルマスタオペレーションと同様のフェイルオーバーオペレーションで。あることに注意してください マルチプルのロジカルスタンバイノードである場合、他のノードは新しいマスタをフォローできません。 そのため、この手法の有効性は事実上1つのロジカル スタンバイ。

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

EDB Postgres ExtendedおよびEDB Postgres Advacedでは、これは自動的に解決されます。スタンバイのスロット同期プロセスは、アップストリームでファンクションを呼び出すことでこれを解決します。このファンクションは、WAL切り替えを実行し、すべてのBDRpeerノードに進行状況の更新をリプレイするように要求することにより、 BDRクラスター全体のグループスロットを移動します。上記により、グループスロットは短期間で先に進みます。これにより、スタンバイが初期スロットの同期アップに必要な時間を短縮し、必要に応じてより高速なフェイルオーバーを可能にします。

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

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

また、WAL切り替えを手動で実行し、すべてのBDRpeerノードに進行状況の更新をリプレイするように要求することにより、BDRcluster全体でスロット同期プロセスをナッジすることもできます。このアクティビティにより、グループスロットが短いタイムスパンで先に移動し、スタンバイのスロット同期アップアクティビティも早まります。このために、ターゲットデータベースの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の変更をmakeことはできますが、それらは複製されず、グローバルDDLロックの取得も試みません。 DDLと同様に機能するBDR関数も複製されません。 [ DDL Replication]を参照してください。ロジカルスタンバイに対して互換性のないDDL変更を行った場合、データベースは分岐ノードと呼ばれます。現在、ダイバージェントノードの昇格はレプリケーションの失敗につながります。そのため、スタンバイとして使用する保証は、ロジカルスタンバイノードにダイバージェントな変更がフリーようにするか、ダイバージェントノードが昇格しないようにする必要があります。

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

BDRは、従来の物理的スタンバイフェイルオーバーノードの作成も可能にします。これらは通常、短い昇格プロシージャの後にクラスタ内のBDRノードを直接置き換えることを意図しています。標準のPostgresクラスターと同様に、ノードにはこれらの物理レプリカがいくつあってもかまいません。

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

BDRプライマリとスタンバイ間の接続はストリーミングを使用します 物理的レプリケーションレプリケーションスロットを介した複製。 - スタンバイには次のものがあります。 - recovery.conf（ PostgreSQL ＆lt; 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に使用されるレプリケーションスロット。

これは、 BDRノードの動作する物理的スタンバイを生成するには十分ですが、対処すべき追加の懸念事項がいくつかあります。

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

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

物理的スタンバイノードが最新であり、（bdr.standby_slot_namesの構成に従って）昇格できることを保証する保護メカニズムは、物理的スタンバイノードが最新の状態になった後にのみグループレプリケーションが発生するため、 BDRグループの全体的なレプリケーションレイテンシに影響します。

これらの理由により、通常、物理的スタンバイノードの代わりにロジカルスタンバイノードまたはサブスクライブ専用グループのいずれかを使用することをお勧めします。両方とも比較してより優れた運用特性を備えているからです。

次のBDRスタンバイを使用して、グループスロットがすべてのノードで（可能物理的限り）進んで構文ように手動で保証できSQL。

SELECT bdr.move_group_slot_all_nodes();

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

  1. Primary.2と同じIPアドレスまたはホスト名の制御を想定します。他のすべてのBDRノードでbdr.alter_node_interfaceファンクションを実行して、アドレスの変更をBDRクラスターに通知します。

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

bdr.standby_slot_namesパラメータにもノートしてください。 Ttは、プライマリ->フィジカルスタンバイのリレーションBDRクラスター、またはサブスクライバーのみのグループを使用する場合に設定することが重要です。

BDRは、アウトバウンドレプリケーションの最大のラグを示すクラスターノードの状態を常に反映するメンバスロットを維持しノード。グループスロットの状態。

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

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

  • スタンバイ時：

    • -primary_conninfoで一意のapplication_nameを指定する

  • プライマリで：

    • -synchronous_commitの有効化

    • -synchronous_standby_namesにスタンバイapplication_nameを含める

insynchronous_standby_namesでは、物理的スタンバイと他のBDRノードを混在させることができます。 CAMOおよびEager All Node Replicationは異なる同期メカニズムを使用し、同期レプリケーションでは機能しません。 synchronous_standby_namesにCAMOパートナー（CAMOが使用されている場合）またはBDRノードがまったく含まれていない（BDR All Node Replicationが使用されている）makeを確認してください。

サブグループ

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

サブスクライバー専用グループ

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

subscriber-onlyノードは完全に結合されたBDRノードであるため、複製されたすべてのDDLを受信し、それらに作用します。また、Raftを使用して、クラスター内のすべてのノードにそのステータスを一貫してレポートします。 subscriber-onlyノードにはRaftの投票権がないため、Raftリーダーになることもリーダー選挙に参加することもできません。また、複製されたDDLを受け取りますが、 DDLまたはDMLロックの取得には参加しません。つまり、現在ダウンしているsubscriber-onlyノードは、DMLロックの取得を停止しません。

subscriber-onlyノードは、 BDR Treetopologyのビルディングブロックを形成します。このトポロジでは、少数の完全にアクティブなノードがあり、すべての方向に変更を複製し、変更を受信するだけでクラスター内の他のノードに変更を送信しないsubscriber-onlyノードが多数あります。このトポロジは、ラージのノードに起因する接続の爆発を防ぎますが、データを消費するために使用できる非常にラージのleafノードを提供します。

オーダーノードを使用するには、ユーザは最初に「サブスクライバーのみ」タイプのBDRグループを作成する必要があります。メンバノードがレプリケーションの変更を受信するグループのサブグループである必要があります。サブグループが作成されると、subscriber-onlyノードになる予定のすべてのノードがサブグループに結合する必要があります。 「サブ親専用」タイプの複数のサブグループを作成でき、異なるサブグループを持つことができます。

ノードが「サブスクライバのみ」のサブグループに正常に参加すると、subscriber-onlyノードになり、親グループのレプリケーション変更の受信をスタートします。 subscriber-onlynodeで直接行われた変更は複製されません。

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

注

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

現時点では、bdr.standby_slot_namesおよびbdr.standby_slots_min_confirmedを適切に設定して、subscriber-onlynodesの前に常に完全にアクティブなBDRノードが存在するようにすることで、これを解決できます。

これは、将来のリリースで改善される可能性があります。レプリケーションで先にb_tran_2ノードを許可してから、同期のためにマスレプリケーションソースを使用するか、別の完全に結合されたノードが分離されたときにクラスターから矛盾するsubscriber-onlyノードをオプションで削除する方法を提供できます。

デコードワーカー

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

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

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

無効にすると、各ノードにサブスクライブしている各ノードに対して、WAL Senderプロセスによってロジカルデコーディングが実行されます。この場合、LCRファイルは書き込まれません。

WDRデコーダーはBDRグループに対して有効になっていますが、次のGUCはノードごとのLCRの生産と使用を制御します。デフォルトでは、これらはfalseです。 LCRの生産と使用のために、BDRグループでWALデコーダーを有効にし、これらのGUCをBDRグループの各ノードでtrueに設定する必要があります。

  • bdr.enable_wal_decoder-falseにすると、WALデコーダーを停止します。 LCRを使用しているWALセンダはWALを使用するために再起動されます。 trueの場合 BDRグループ構成とともに、WALデコーダーが実行され、LCRとWALが生成されます 送信者はLCRを使用します。

  • bdr.receive_lcr-サブスクライブしているノードのtrueがWALを要求する場合 利用可能な場合、LCRを使用するためにパブリッシャーノードで送信します。

メモ

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

購読者専用ノードはそれぞれのノードから直接変更を受信するため、購読者専用ノードにサービスを提供するWAL送信者はLCRを使用できます。

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

リファレンスまでに、LCRファイル名の最初の24文字はWALファイル名のものと似ています。現在、名前の最初の8文字はすべて「0」です。将来的には、WALセグメントファイル名の最初の8文字と同様に、TimeLineIdを表すと予想されます。名前の16文字の次のシーケンスは、WALストリームに対してLCRchangesを追跡するのに使用されるWALセグメント番号と同様です。ノート、ロジカル変更は、下位のトランザクションのコミットオーダーに従って並べ替えられます。したがって、LCRセグメントでの配置は、WALセグメントでの対応するWALの配置とマッチしません。最後の16文字のセットは、LCRセグメント内のサブセグメント番号を表します。各LCRファイルはサブセグメントに対応しています。 LCRファイルはバイナリサイズで変数サイズです。 LCRファイルの最大サイズは、bdr.max_lcr_segment_file_sizeで制御できます。デフォルトは1GBです。

この機能を動作させるには、 EDB Postgres Extended 13以降が必要です。

ノードの再起動とノードの復旧

BDRは、ノードのリスタートまたはノードの切断から回復するように設計されています。切断されたノードは、各同等なに再接続し、そのノードから不足しているデータを複製することにより、グループに自動的に再参加しノード。

ノードが起動すると、各接続は同等な = catchupの表示を開始し、欠落したデータの複製を開始しノード。サーバーのワークロード。

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

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

ノードノードはオフラインノードを保持するため（同等なごとに1つを使用）、後で一時的にストレージできないノードへの変更をリプレイスペースノード。で* WAL *）、データベースサーバーが次のようなエラーでシャットダウンする可能性があります：

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

…またはその他のディスク外関連の症状をレポートします。

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

EDB Postgres Extendedでは、オフラインノードもデータの凍結を抑制して、競合解決データの損失を防ぎます（参照：）。

管理者はノードの停止をモニタし（参照：）、ノードに十分なフリーディスクスペースがあるmake必要があります。ワークロードが予測可能な場合、時間の経過とともに使用されるスペースの量を計算できるため、重大な問題が発生する前にノードがダウンできる最大時間を予測できます。

BDRによって作成された複製スロットは、手動で削除しないでください。その場合は、クラスターが破損し、スロットを使用していたノードをクラスターから切り離す必要があります（以下を参照）。

ノードがオフラインになっている間、他のノードはまだオフラインノードから同じデータセットを受信していない可能性があるため、ノード間でわずかな相違として表示されることに注意してください。ノード間のこの不均衡は、分割プロセス中に自動的に修正されます。これより後のバージョンでは、これが以前に行われる可能性があります。

BDRによって作成された複製スロット

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

  • bdr_<database name>_<group name>名前付けの1つのグループスロット。

  • N-1 ノードスロット、名前付けはbdr_ <データベース名前> _ <グループ名前> _ <ノード 名前>、Nはクラスター内のBDRノードの総数、 ダイレクトロジカルスタンバイ（ある場合）を含む。

ユーザはこれらのスロットを削除してはいけません。これらはBDRによって自動的に作成されており、 BDRによって管理されます。

一方、Barmanorロジカルレプリケーションなどのソフトウェアに必要なレプリケーションスロットは、 BDRに影響を与えることなく、ソフトウェアの適切なコマンドを使用して作成またはドロップできます。 bdr_。

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

  • ノードalphaには3つのスロットがあります。

  • bdr_mydb_mygroup名前付けの1つのグループスロット

  • bdr_mydb_mygroup_beta名前付けの2つのノードスロットと bdr_mydb_mygroup_gamma

  • ノードbetaには3つのスロットがあります。

  • bdr_mydb_mygroup名前付けの1つのグループスロット

  • bdr_mydb_mygroup_alpha名前付けの2つのノードスロットと bdr_mydb_mygroup_gamma

  • ノードgammaには3つのスロットがあります。

  • bdr_mydb_mygroup名前付けの1つのグループスロット

  • bdr_mydb_mygroup_alpha名前付けの2つのノードスロットと bdr_mydb_mygroup_beta

グループ複製スロット

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

グループスロット名前は、bdr.local_group_slot_name()ファンクションによって指定されます。

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

  • 既存のノードをすべて持たずに、新しいノードをBDRグループに結合させる 稼働中（ただし、ノードの大部分は稼働している必要があります）、なし 結合中にダウンしていたノードが起動した場合にデータロスが発生する 再び複製する

  • パートのノードが一貫していない場合でも、クラスターからのノードを一貫して 別れたノードに完全に追いついた

  • いくつかの競合を見逃さないようにフリーズポイントを抑えます（EDB Postgres Extended）

  • タイムスタンプベースのスナップショットの履歴snapshotを保持します（ EDB Postgres Extended）

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

警告：グループスロットをドロップしないでください。通常はアクティブではありませんが、 BDRクラスターの適切なオペレーションには依然として重要です。削除された場合、上記の機能の一部またはすべてが機能しなくなり、および/または誤った結果になる可能性があります。

ロング識別子のハッシュ

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

この例として、group20xxxxxxxxxxxxx（20バイト長）という名前のBDRグループを使用して、db20xxxxxxxxxxxxxxxx（20バイト長）という名前のデータベースを複製するクラスターを考えます。ノードa30xxxxxxxxxxxxxxxxxxxxxxxxxxx（30バイト長）に関連付けられたロジカルレプリケーションスロットが呼び出されます。

bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2

… 3597186、be9cbd0、7f304a2はそれぞれdb20xxxxxxxxxxxxxxxx、group20xxxxxxxxxxxxx、a30xxxxxxxxxxxxxxxxxxxxxxxxxxのハッシュであるため。

BDRグループからノードを削除する

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

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

結合プロシージャと同様に、分割はRaftコンセンサスを使用して行われ、多数のノードが動作するようにオンラインにする必要があります。

分離プロセスはすべてのノードに影響します。 Raftリーダーは、ノード間の投票を管理して、別のノードからの最新のデータを持つノードを確認します。その後、残りのすべてのノードは、最新のノードに二次的なの一時makeな接続を確立し、欠落データをキャッチします。

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

BDRのアンインストール

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

DROP EXTENSION bdr;

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

  • timeshardやgallocなどのBDR固有のシーケンスを使用するテーブル

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

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

これらの依存関係は、 BDR拡張機能を削除する前に削除する必要がありインスタンス、依存オブジェクトを削除する、列タイプを非BDRに変更する、シーケンスタイプをtolocalに戻すなどです。

BDR BDRメタデータ機能のドロップは、ノードがそのBDRノードグループから正常に分離された場合、またはグループ内の最後のノードである場合にのみ実行レプリケーション必要があります。

!!! Warning * ローカル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()は実行されましたが、ノードは BDRクラスターのメンバ。

  • JOIN_START： 結合は、ローカルノードを 既存のBDRクラスター。

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

  • CATCHUP：初期同期フェーズが完了しました。結合は最後のステップになりました アップストリームで実行されたトランザクションの取得と適用の 結合が開始されノードからの同等な。

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

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

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

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

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

  • 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-ノードへの接続文字列

注

このファンクションは、関連付けられたpublic接続文字列でローカルノードのレコードを作成するだけです。ローカルレコードは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()を使用してノードを既に分離している必要があります。

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

!!! Note * BDR4は、一度に最大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’、 「読み取りコーディネーター」および「書き込みコーディネーター」。 「加入者専用」タイプは からの変更のみを受け取るノードのグループを作成するために使用されます クラスター内の完全に参加したノードが、レプリケーションを送信しない 他のノードへの変更。詳細については、「サブスクライバー専用ノード」を参照してください。 データノードは、グループがシャードを表すことを意味しますが、もう一方は 値は、グループがそれぞれのコーディネーターを表すことを意味します。 「サブスクライバーのみ」を除き、残りの3つの値は将来の使用のために予約れています。 NULLは、通常の汎用ノードグループが作成されることを意味します。

注

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

ファンクションはトランザクションではありません。グループの作成はバックグラウンドプロセスであるため、ファンクションが終了すると、変更をロールバックできません。また、変更は現在のトランザクションにすぐに可視されない場合があります。

グループの作成はロックを保持しません。

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)

パラメーター

  • 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-WALデコーダープロセスを有効/無効にします。に注意してください streaming_modeが既にある場合、WALデコーダープロセスを有効にできません。 有効。

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

注

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

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

このファンクションはロックを保持しません。

!!! Warning * このファンクションを使用して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-構造（スキーマ）の同期の種類を設定します 結合中に行われるべきです。有効なオプションは、同期する「すべて」です 完全なデータベース構造、および同期しない「なし」 構造（ただし、データは引き続き同期されます）。

wait_for_completionがfalseとして指定されている場合、これは、参加プロシージャが開始されるとすぐに返される非同期呼び出しです。結合の進行状況は、ログおよびthebdr.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によって設定されたtargetstateに到達するまで待機します。

bdr.part_node

BDRグループからノードを削除（「パーツ」）しますが、ノードからデータを削除しません。

このファンクションは、削除されるノードを含むBDRグループ内のアクティブなノードから呼び出すことができます。ただし、明確にmakeに、ノードがPARTEDされると、クラスタ内の他のノードをパートすることはできません。

!!! Note * あなたはwait_for_completionをfalseに設定しなければならないローカルノードを「分割」しています。そうでなければエラーになります。

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

あらすじ

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

パラメーター

  • node_name-パートする既存のノードの名前。 結果 -trueの場合、ファンクションは ノードはクラスターから完全に切り離されます。そうでない場合、ファンクションは単に 別れプロシージャをスタートし、待機せずにすぐに結果ます。 ローカルノードで実行する場合、または強制を使用する場合は、常にfalseに設定します。

  • force-ローカルノードのノードを強制的に削除します。これにより コンセンサスに到達できなかった場合、またはノードが別れた場合、ノードの状態はローカルに プロセスが停止しました。

!!! Warning * 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ノードのすべてのサブスクリプションを無効にします。必要に応じて、無効なサブスクリプションに関連付けられているすべてのワーカーをすぐに停止することもできます。 pausesubscriptionとも呼ばれます。サブスクリプションがすでに無効になっている場合、エラーはスローされません。このオペレーションの影響を受けるサブスクリプションの数を返します。

あらすじ

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

パラメーター

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

  • immediate-即時を使用してアクションをすぐに強制し、停止します 無効サブスクリプションに関連付けられているすべてのワーカー。このオプションで true、このファンクションはトランザクションブロック内で実行できません。

注

このファンクションは複製されず、ローカルノードのサブスクリプション（特定のサブスクリプションまたはすべてのサブスクリプション）にのみ影響します。

このファンクションはトランザクションです。ロールバックでき、現在のトランザクションでカタログの変更を確認できます。ただし、subscriptionworkerが停止するタイミングはimmediateの値に依存します。 trueに設定されている場合、ワーカーはすぐに停止します。 falseに設定すると、COMMITの時点で停止します。

ノード管理コマンド

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

bdr_init_physical

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

ユーザはデータディレクトリを指定する必要があります。このデータディレクトリが空の場合、pg_basebackup -X streamコマンドを使用して、高速ブロックレベルコピーオペレーションを使用してディレクトリを埋めます。

空のデータディレクトリから開始する場合、選択的バックアップオプションを選択すると、そのデータベースのみがソースノードからコピーされます。除外されたデータベースは削除され、新しいノード（EDB Postgres Extended）でクリーンアップされます。

指定されたデータディレクトリが空でない場合、これが新しいノードのベースとして使用されます。データディレクトリがすでに物理的なスタンバイノードとしてアクティブになっている場合、 Postgres自分自身を管理するbdr_init_physicalを実行する前にスタンバイを停止する必要があります。最初はキャッチアップを待機し、その後BDRグループに参加する前にマスタノードにプロモートします。 --standbyオプションを使用すると、既存の物理スタンバイがロジカルスタンバイノードに変わることに注意してください。それは新しいBDRノードの終わりstateofを示します、指定されたデータディレクトリの開始状態ではありません。

このコマンドは、すべてのPostgreSQLネイティブロジカル複製サブスクリプションをデータベースから削除します（または、-Sオプションが使用されている場合は単に無効にします）。また、レプリケーション起点元とスロットも削除します。

あらすじ

bdr_init_physical [OPTION] ...

オプション

一般オプション

  • -D, --pgdata=DIRECTORY-新しいノードに使用されるデータディレクトリ。それ 空のディレクトリまたは存在しないディレクトリのいずれか、または pg_basebackup -X streamコマンド（必須）。

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

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

  • --replication-sets=SETS-レプリケーションのコンマ区切りリストの名前 使用する名前を設定します。指定しない場合、すべてのレプリケーションセットが使用されます。

  • --standby-完全ではなく、ロジカルスタンバイ（ノードのみを受信）を作成します 送受信ノード。

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

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

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

  • -L-と組み合わせて使用すると、選択的なpg_basebackupを実行します 空/存在しないデータディレクトリ（-Dオプション）。 （EDB Postgres Extended）

  • -S-ロジカルレプリケーションサブスクリプションを削除する代わりに、単に無効にします それら。

接続オプション

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

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

設定ファイルの上書き

  • 新しいpg_hba.confへの--hba-conf -path

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

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

注

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

不要なテーブルは、結合の完了後に演算子によって切り捨てられる場合があります。bdr.tablesカタログを参照して、レプリケーションセットのメンバーシップを確認し、サブスクライブ先のレプリケーションセットのメンバーではないテーブルを識別します。次の理由により、テーブルを削除するのではなく、切り捨てることを強くお勧めします。

  1. DDLレプリケーションセットは必ずしも行（DML）レプリケーションセットと同じではないため、他のノードにテーブルを誤ってドロップする可能性があります。後でテーブルをレプリケーションセットに追加し、ノードの一部のサブセットにドロップした場合、レプリケーションに追加する前に、 DDLの競合を作成せずにそれらのノードでのみテーブルを再作成するように注意する必要がありますセット。

レプリケートされていないテーブルを切り捨て、存在するが空のままにする方がはるかに簡単で安全です。

BDRの将来のバージョンでは、物理的結合の選択されたレプリケーションセットに含まれないテーブルを自動的に削除または削除する可能性があるため、アプリケーションはここに記載されている動作の詳細に依存しません。