Node management

ノード状態のリスト

  • NONE ：ワーカーの起動時にノードの状態は設定解除され、現在の既知の状態に迅速に設定されることが期待されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

ノード管理コマンド

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

bdr_init_physical

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

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

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

このコマンドは、データベースからすべての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 へのパス。

注意事項

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

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

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

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

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