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`` オプションを使用する場合を無効にします。また、レプリケーションオリジンとスロットも削除します。 概要 ^^^^ .. code:: shell 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競合を作成せずにこれらのノードでのみ再作成する必要があります。 非レプリケートテーブルを切り捨て、存在するが空のままにする方が簡単かつ安全です。