Node Management

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

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

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

BDRグループの作成と参加

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

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

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

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

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

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

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

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

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

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

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

ノード結合は、結合にかかる時間の大部分を他のノードジョインと同時に実行できます。ただし、一度に1つの通常ノードのみがPROMOTEまたは結合の状態になります。他のすべてのノードが稼働している場合、通常はかなり短くなります。サブスクライバー専用ノードはこのルールの例外であり、同時に 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を実行しているBDRクラスタに結合できます。このプロシージャは、ユーザがBDRメジャーバージョンだけでなく、基になるPostgreSQLメジャーバージョンもアップグレードする場合に役立ちます。これは、 PostgreSQL 12または13で実行されている3.7ノードをPostgreSQL 11でPostgreSQLを実行しているBDRクラスターに参加することで実現できメジャーリリース。 もちろん、新しいノードは、既存のクラスター。

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アドレスのサブジェクト代替名をサポートしていないため、接続が名前ではなく address で行われる場合、 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 には、ノードをロジカルスタンバイノードとして途中で結合したままにmakeのpause_in_standbyオプションがあります。ロジカルスタンバイノードは変更を受信しますが、ローカルに加えられた変更を他のノードに送信しません。

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

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

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

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

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

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

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

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変更をmakeことができますが、それらはレプリケートされず、グローバルDDLロックを取得しようとしません。 DDLと同様に機能するBDRファンクションもレプリケートされません。

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

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

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

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

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

  • スタンバイには以下があります。- レプリケーションスロット （ PostgreSQL <12の場合、これらの設定は物理的にある必要がありPostgreSQL）： 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グループの全体的なレプリケーションのレイテンシに影響します。

これらの理由から、一般的には、物理的スタンバイノードではなく、ロジカルスタンバイノードまたはサブスクライブ専用グループのいずれかを使用することをお勧めします。

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

SELECT bdr.move_group_slot_all_nodes();

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

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

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

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

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

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が使用されている場合）makeを確認してください。フィジカルスタンバイなどの非BDRノードのみが含まれます。

サブグループ

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

加入者専用グループ

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

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

subscriber-only ノードは、 BDRツリートポロジのビルディングブロックを形成します。このトポロジでは、少数の完全にアクティブなノードがすべての方向に変更を複製し、変更を受信するのみでクラスター内の他のノードに変更を送信しないラージのsubscriber-only ノードがあります。このトポロジーは、多数のノードが原因で発生する接続の爆発を回避しますが、データの使用に使用できるラージにラージのleaf ノードを提供します。

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

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

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

注意事項

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

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

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

デコードワーカー

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

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

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

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

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

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

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

ノート

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

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

LCRが生成されても、対応するWALはDecoding Workerが有効になっていない場合と同様に保持されます。将来、LCRに対応するWALが必要ない場合は、削除できる場合があります。

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

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

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

ノードが起動すると、各接続は bdr.node_slots.state = catchup を表示し始め、欠損データの複製を開始します。キャッチアップは、各同等なからの欠落ノードの量に応じて一定期間継続され、サーバーのワークロードに応じて、時間の経過とともに増加する可能性があります。

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

ノードが長時間（数時間や数日など）オフラインになると、さまざまな理由でリソースの問題が発生し始める可能性があります。ユーザーは、次の問題を理解することなく、拡張の停止を計画しないでください。

各ノードは変更情報を保持する（同等なごとに1つの BDRによって作成されたレプリケーションスロット を使用）ため、一時的に到達できないノードへの変更を後でリプレイできノード。同等なが無期限にオフラインのままであるノードでノードPostgreSQLトランザクション（ スペースの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では、オフラインノードもデータのフリーズを保持して、競合解決データの損失を防ぎます（

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

BDRによって作成されたレプリケーションスロットは手動で削除しないでください。その場合、クラスターが破損しているため、以下で説明するように、スロットを使用していたノードをクラスターから分離する必要があります。

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

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

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

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

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

ユーザはこれらのスロットをドロップしてはなりません**。これらはBDRBDR管理され、必要に応じてドロップします。

一方、 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グループに結合させます

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

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

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

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

警告 : グループスロットを落とさないでください。通常は非アクティブですが、 BDRクラスタが適切にオペレーションするためには不可欠です。削除された場合、上記の機能の一部またはすべてが動作しなくなったり、誤った結果が発生する可能性があります。

長い識別子のハッシュ

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

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

bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2

…since 3597186 、be9cbd0 、7f304a2 は、それぞれdb20xxxxxxxxxxxxxxxx 、group20xxxxxxxxxxxxx 、a30xxxxxxxxxxxxxxxxxxxxxxxxxx のハッシュです。

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

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

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

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

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

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

BDRのアンインストール

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

DROP EXTENSION bdr;

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

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

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

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

これらの依存関係は、 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() は実行されましたが、ノードはまだBDRクラスタのメンバではありません。

  • JOIN_START ： bdr.join_node_group() はローカルノードを既存のBDRクラスタに結合させ始めます。

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

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

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

  • PROMOTE ：ノードはロジカルスタンバイであり、 bdr.promote_nodeを呼び出してノードの状態をACTIVE に移動しました。これら2つのPROMOTE 状態は、1つのノードのみがSTANDBY よりも高く、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 -ノードへの接続文字列

注意事項

このファンクションは、関連付けられたパブリック接続文字列を使用してローカルノードのレコードを作成するだけです。ローカルレコードは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は、一度に最大1024個のノードレコード（ACTIVEとPARTEDの両方）を持つことができます。これは、snowflakeidおよびtimehardシーケンスで使用するために、各ノードに一意のシーケンス番号が割り当てられているためです。 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 Nodes を参照してください。データノードは、グループがシャードを表すことを意味しますが、他の値はグループがそれぞれのコーディネーターを表すことを意味します。 「subscriber-only」を除き、残りの3つの値は将来の使用のために予約れています。 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 -Decoding Workerプロセスを有効/無効にします。 streaming_mode が既に有効になっている場合、Decoding Workerプロセスを有効にできないことに注意してください。

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

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

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

注意事項

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

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

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

警告

このファンクションを使用して`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グループ内のアクティブなノードから呼び出すことができます。ただし、明確にしmakeおくと、ノードがPARTEDになると、クラスター内の他のノードをパートできません。

注釈

ローカルノードを*分割*する場合は、 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の場合、ノードがクラスターから完全に分離されるまで、ファンクションは結果ません。それ以外の場合、ファンクションは分離プロシージャをスタートし、待機せずにすぐに結果ます。ローカルノードで実行する場合、または強制を使用する場合は常にfalseに設定します。

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

警告

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

注意事項

このファンクションは、指定されたノードをパートするためのリクエストをグループコンセンサスメカニズムに渡しノード。加えられた変更は、コンセンサスメカニズムを介してグローバルに複製されます。別れのプロセスはバックグラウンドで行われるため、ロールバックできません。 wait_for_completion がtrue に設定されている場合、分割プロセスによる変更はローカルトランザクションでのみ可視されます。

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

分離プロセスはロックを保持しません。

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 - Immediateを使用してアクションをすぐに強制し、無効になっているサブスクリプションに関連付けられているすべてのワーカーを停止します。このオプションがtrueの場合、このファンクションはトランザクションブロック内で実行できません。

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

注意事項

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

このファンクションはトランザクションです。ロールバックでき、現在のトランザクションでカタログの変更を確認できます。ただし、サブスクリプションワーカーが停止するタイミングは immediate の値に依存します。 true に設定されている場合、ワーカーはCOMMIT を待機する前に停止を受け取り、 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です。ログ。

  • -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 -path を新しい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 カタログを参照して、レプリケーションセットのメンバーシップを判断し、サブスクライブしたレプリケーションセットのメンバーではないテーブルを特定します。次の理由から、テーブルは削除せずに切り捨てることを強くお勧めします。

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

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

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

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