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グループに追加するためのコマンドラインユーティリティも提供します。

bdr_init_physical#

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

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

指定されたデータディレクトリが空でない場合、新しいノードのベースとして使用されます。最初にキャッチアップを待機し、PGDグループに参加する前にマスターノードに昇格します。 --standby オプションを使用する場合、ロジカルスタンバイノードに変わります。

このコマンドは、すべての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競合を作成せずにこれらのノードでのみ再作成する必要があります。

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