Transferring data to the seed node
==================================

このフェーズでは、物理レプリケーションを介してソースノードをミラーリングするシードノードにデータベースのスタンバイコピーを作成することにより、シードノードを初期化します。このスタンバイは、最終的なPGDクラスターのシードノードとして機能します。既存のクラスターへの干渉を最小限に抑えるために、特にフェールオーバーマネージャーEFMによって管理されている場合、このレプリカは手動で追加されます。

論理レプリケーションのソースノードの準備
----------------------------------------

論理レプリケーションに移行するには、シードノードを準備する必要があります。まだ有効になっていない場合は、ソースノードで\ ``wal_level``
を\ ``logical``
に設定します。この変更にはデータベースの再起動が必要であるため、この手順を事前に実行することをお勧めします。

1. ソースノードで次のコマンドを実行します。

.. code:: sql

      ALTER SYSTEM SET wal_level = logical;

1. ソースノードのPostgresサービスを再起動して、構成の変更を有効にします。

.. code:: bash

      su -u enterprisedb --command "pg_ctl restart"

1. 再起動後、\ ``wal_level``
   が正しいこと、および十分なレプリケーションスロットとワーカープロセスが使用可能なことを確認します。
   **M** の既存のスタンバイと **N**
   の将来のPGDノードを使用したセットアップの場合、これらのパラメーターが少なくとも以下に示されているものであることを確認します。

.. code:: sql

      SHOW wal_level;                         -- Expected logical

      SHOW max_replication_slots;             -- Must be at least M + N
      SHOW max_wal_senders;                   -- Must be at least M + N
      SHOW max_logical_replication_workers;   -- Must be at least N

アウトバウンド論理レプリケーションの許可
----------------------------------------

外部論理接続を許可するようにソース環境を構成し、移行ストリームに必要な認証資格情報を確立します。

1. ソースノードには、データの移行を促進するためにレプリケーション特権を持つロールが必要です。既存のロールを使用するか、別のロールを作成できます。例

.. code:: sql

      CREATE ROLE repl LOGIN NOSUPERUSER REPLICATION PASSWORD your_password_here;

EDBは、 ``.pgpass``
ファイルを使用して、接続文字列DSNにパスワードを含めずに資格情報を安全に管理することをお勧めします。

1. 次のコマンドを使用してPGDノードからの接続を検証し、対話型のパスワード入力なしで接続できることを確認します。

.. code:: bash

      su -u enterprisedb -c "psql --no-password ${SOURCE_DSN} replication=1 \
      --command IDENTIFY SYSTEM"

シードノードと将来のすべてのPGDノード間の接続を必ずテストします。これには、ソースノードで\ ``pg_hba.conf``
の更新が必要になる場合があります。

シードノードの準備
------------------

物理的バックアップに対応できるように、シードノードにPostgresの同じディストリビューションとバージョンをインストールします。詳細は、
`Installing EPAS <https://www.enterprisedb.com/docs/epas/latest/installing/>`_  、 `Installing PGE <https://www.enterprisedb.com/docs/pge/latest/installing/>`_  、または
:ref:`Postgresのインストール <Postgresのインストール>` を参照してください。

..  Note::
  移行中に手動で管理する必要があるため、シードノードにEFMをインストールしないでください。

物理的バックアップの作成
------------------------

ソースの構成が完了したら、シードノードから次のコマンドを実行して、ソースノードからデータベースの物理スナップショットを取得します。転送を開始する前に、宛先の\ ``${PGDATA}``
ディレクトリが存在しないことを確認してください。

.. code:: bash

   su -u enterprisedb -c "pg_basebackup ${SOURCE_DSN}    \
     --pgdata=$(PGDATA)                                    \
     --write-recovery-conf                                 \
     --wal-method=stream                                   \
     --create-slot                                         \
     --slot=migration_phy_slot                             \
     --progress                                            \
     --verbose"

このコマンドは、デフォルトでスプレッドチェックポイントを使用して、ソースノードへのI/Oインパクトを最小限に抑えます。より高いディスクI/Oを犠牲にして転送を高速化するには、\ ``--checkpoint=fast``
を追加できます。

転送時間は、データの合計量と、ソースノードとシードノード間のネットワーク帯域幅によって異なります。帯域幅が制限されている環境の場合、詳細な構成オプションに\`–compress-level=
 
`0-9]` flag to optimize the transfer speed; refer to the official [pg_basebackup documentation <https://www.postgresql.org/docs/14/app-pgbasebackup.html>`_ を使用して圧縮を有効にできます。

シードノードの構成と起動
------------------------

1. 転送が完了したら、シードノードの\ ``postgresql.conf``
   および\ ``pg_hba.conf``
   を調整して、ローカル環境ホスト名、IPアドレス、パスを反映します。シードノードのレプリケーション設定がPGDの要件と一致することを検証します。

.. code:: sql

      SHOW wal_level;                         -- Expected: logical
      SHOW max_replication_slots;             -- Should be at least M + N
      SHOW max_wal_senders;                   -- Should be at least M + N
      SHOW max_logical_replication_workers;   -- Should be at least N

1. シードノードでデータベースを起動して、ストリーミングを開始します。

.. code:: bash

      su -u enterprisedb --command "pg_ctl start"

物理的レプリケーションの検証
----------------------------

ソースノードとシードノードの両方からレプリケーションステータスを監視して、それらが同期されていることを確認します。

ソースノードで

1. 移行スロットのステータスを確認します。 ``lag_size``
   が低いまたは減少しているシードノードに割り当てられたスロットを表示する必要があります。

.. code:: sql

      SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
              pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag_size
      FROM pg_replication_slots
      WHERE slot_name = migration_phy_slot;

1. アクティブな接続を確認します。シードノードのIPアドレスがレプリケーション統計に表示されることを確認します。

.. code:: sql

      SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
              pg_size_pretty(pg_wal_lsn_diff(sent_lsn, replay_lsn)) AS replay_lag
      FROM pg_stat_replication;

シードノードで

1. リカバリモードを確認します。ノードはスタンバイとして正しく動作している必要があります。

.. code:: sql

      SELECT pg_is_in_recovery();             -- Must return true

1. WALレシーバーのステータスを確認します。プライマリソースノードへの接続の状態を確認します。

.. code:: sql

      SELECT slot_name, sender_host || : || sender_port AS sender, status,
      now() - last_msg_send_time    AS last_msg_send_age,
      now() - last_msg_receipt_time AS last_msg_receipt_age,
      now() - latest_end_time       AS last_end_age,
      pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, written_lsn)) AS write_lag_size,
      pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, flushed_lsn)) AS flush_lag_size
      FROM pg_stat_wal_receiver;

1. 受信位置と再生位置を比較します。これにより、再生ラグ-受信されたがデータベースにまだ適用されていないデータの量が特定されます。

.. code:: sql

      SELECT pg_size_pretty(pg_wal_lsn_diff(pg_last_wal_receive_lsn(),
                                          pg_last_wal_replay_lsn())) AS lag_bytes;

1. 時間ごとに遅延を監視します。現在の時間と最後に再生されたトランジションの時間差を測定します。

.. code:: sql

      SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds;

次のステップ :ref:`Converting to logical replication <Converting to logical replication>`  。