Node management
===============

ノードの状態のリスト
--------------------

.. csv-table::
  :header: State,Description
  :widths: 10,30
  :align: left
  :class: longtable

  `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`であり、 EDB Postgres分散クラスターからノードを削除するために`bdr.part_node`が呼び出されたばかりです。
  `PARTING`,ノードは他のノードから切断し、コンセンサスまたはレプリケーションでそれ以上の役割を果たしません。
  `PART_CATCHUP`,分割されていないノードは、最近分割されたノードから欠落しているデータを同期します。
  `PART_CLEANUP`,非分割ノードは、すべてのノードのグループスロットがPARTEDノードから発生したすべてのトランザクションに追いつくまで待機します。
  `PARTED`,これで、すべてのノードでノード分離操作が完了しました。
  `PARTED_CONCURRENT`,ノード分割操作がコンカレントオプションで開始されました。

``PROMOTE`` または\ ``PROMOTING``
のいずれかのノードになることは、一度に1つのノードのみです。

``PARTED_CONCURRENT``
状態はターゲット状態として使用され、\ ``concurrent = true``
オプションで分割が行われたことを示します。

ノード管理コマンド
------------------

PGDは、既存のノードの物理コピー ``pg_basebackup``
を使用してノードをPGDグループに追加するためのコマンドラインユーティリティも提供します。

bdr_init_physical
^^^^^^^^^^^^^^^^^

..  Warning Deprecated::
   このコマンドは、 PGDグループ内のノードを作成および管理するより柔軟で強力な方法を提供するpgd CLIコマンド `pgd node setup <https://www.enterprisedb.com/docs/pgd/latest/reference/cli/command_ref/node/setup>`_ の使用を優先して非推奨です。 `bdr_init_physical` は、将来的にバグ修正のみを受け取ります。新規インストールにはお勧めできません。

.. ::
   .. ::
   `bdr_init_physical` では、ソースノードと参加ノードの両方がまったく同じPGDバージョンであることが必要です。このコマンドを使用して、別のPGDバージョンのノードを既存のクラスターに参加させることはできません。これは、ノード参加方法を使用したローリングアップグレードに`bdr_init_physical` を使用できないことを意味します。ローリングアップグレードの場合、代わりに論理結合を使用します。詳細については、 :ref:`ノード参加を使用したローリングアップグレード <ノード参加を使用したローリングアップグレード>` を参照してください。

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

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

bdr_config
^^^^^^^^^^

このコマンドラインユーティリティを使用すると、PGDインストールの構成を確認できます。これは、
PostgreSQLに付属する\ ``pg_config``
ユーティリティに似ています。トラブルシューティングとサポートを支援するために使用できます。

.. _概要-1:

概要
^^^^

.. code:: shell

   bdr_config [OPTION] ...

.. _オプション-1:

オプション
^^^^^^^^^^

.. csv-table::
  :header: Option          ,Description
  :widths: 10,30
  :align: left
  :class: longtable

  `--all`,構成内のすべてのキーと値を表示します。
  `--version`,BDRバージョン関連のキーと値のみを表示します。これには、 BDR拡張機能のフルバージョン、それが実行されているPostgresバージョンとフレーバー、およびBDRPGおよびBDRプラグインAPIバージョンが含まれます。
  `--debug`,ビルド情報や機能の有効化を含む、 BDRデバッグキーと値のみを表示します。

例
^^

.. code:: shell

   $ /usr/lib/edb-as/16/bin/bdr_config --all
   __OUTPUT__
   BDR_VERSION_COMPLETE=5.6.0
   BDR_VERSION_NUM=50600
   PG_VERSION=16.4.1 (Debian 16.4.1~~snapshot11329862135.2980.1.88fbec6-1.bookworm)
   PG_VERSION_NUM=160004
   PG_FLAVOR=EPAS
   BDRPG_API_VERSION_NUM=202309131
   BDR_PLUGIN_API_VERSION=7011
   USE_ASSERT_CHECKING=false
   USE_VALGRIND=false
   EXT_ENABLE_DTRACE=false
   HAVE_LAG_CONTROL=true
   HAVE_ASSESS_UPDATE_RI_HOOK=false
   HAVE_BDRPG_PROBES=false
   HAVE_CAMO=true
   HAVE_DEADLOCK_DETECTOR_HOOK=true
   HAVE_HEAP_UPDATE_HOOK=true
   HAVE_LAG_TRACKER=true
   HAVE_LCR=true
   HAVE_LOG_TOAST_COLUMNS=false
   HAVE_MISC_HOOKS=true
   HAVE_MISSING_PARTITION_CONFLICT=true
   HAVE_MULTI_PITR=false
   HAVE_SELECTIVE_BASEBACKUP=false
   HAVE_STREAMING_XACTS=true
   HAVE_SYNC_COMMIT_HOOK=true
   HAVE_TWOPHASE_DATA_HOOKS=true
   HAVE_XLOG_FIND_NEXT_RECORD=true
   HAVE_DETACH_CONCURRENTLY=true
   HAVE_ANALYTICS=true
