Upgrading the seed node and installing PGD

Upgrading the seed node and installing PGD#

このフェーズでは、シードノードでPostgresディストリビューションのメジャーバージョンのアップグレードを実行し、 Postgres Distributed用に準備します。

アップグレードのシードノードの準備#

メジャーバージョンのアップグレードを実行するには、シードノードをオフラインにする必要があります。アップグレード後にサブスクリプションのメタデータを手動で更新する必要があるため、サービスを停止する前に論理サブスクリプションを無効にすることを強くお勧めします。

  1. シードノードで、論理レプリケーションを無効にします。

ALTER SUBSCRIPTION migration_seed_sub DISABLE;

  1. シードノードで既存のPostgresインスタンスを停止します。

su -u enterprisedb --command "pg_ctl stop"

  1. ターゲットバージョンのパッケージをシードノードにインストールします。 pg_upgrade は、移行を実行するために両方のバージョンのバイナリを必要とするため、古いバージョンがインストールされたままであることを確認します。詳細は、 Installing EPAS 、 Installing PGE 、または Postgresのインストール を参照してください。

  2. 新しいバイナリたとえば /usr/edb/as17/bin/ を指すように${PATH} 環境変数を調整し、バージョンを確認します。

which pg_ctl

インプレースアップグレードの実行#

データファイルをコピーする代わりにハードリンクを使用するインプレースアップグレードには、 --link フラグをpg_upgrade とともに使用します。これにより、必要なディスク領域と時間が大幅に削減されますが、古い ${OLD_PGDATA} と新しい ${NEW_PGDATA} ディレクトリの両方が同じファイルシステム上に存在する必要があります。

  1. シードノードで、新しいデータディレクトリを準備します。

OLD_PGDATA = ${PGDATA}
unset PGDATA
mkdir ${NEW_PGDATA}
chown enterprisedb: ${NEW_PGDATA}
chmod 700 ${NEW_PGDATA}
su enterprisedb -c "initdb -D ${NEW_PGDATA} -E utf-8"

  1. シードノードで、最初にチェックモードでpg_upgrade を実行します。

mkdir /tmp/pg_upgrade
cd /tmp/pg_upgrade
su postgres -c "pg_upgrade \
--old-datadir ${OLD_PGDATA} \
--new-datadir ${NEW_PGDATA} \
--old-bindir /usr/edb/as14/bin/ \
--new-bindir /usr/edb/as17/bin/ \
--link \
--check"

  1. チェックで肯定的な結果が返された場合は、 --check フラグを使用せずに同じコマンドを実行して、実際のアップグレードを実行します。

cd /tmp/pg_upgrade
su postgres -c "pg_upgrade \
--old-datadir ${OLD_PGDATA} \
--new-datadir ${NEW_PGDATA} \
--old-bindir /usr/edb/as14/bin/ \
--new-bindir /usr/edb/as17/bin/ \
--link"

  1. 完了したら、Postgresディストリビューションの新しいバージョンを起動します。

su -u enterprisedb --command "pg_ctl start"

サブスクリプションの再有効化#

メジャーバージョンのアップグレードでは、サブスクリプションの内部テーブルマッピング情報は引き継がれません。特に、カタログテーブルpg_subscription_rel は空になります。サブスクリプションをすぐに有効にすると、テーブルデータを同期せずにレプリケーションスロットが前方に移動され、データ損失が発生します。

これを回避するには、サブスクリプションを「偽構成」して、テーブルメタデータの更新中に実際のスロットを進めないようにする必要があります。存在しないスロットについてシードノードログで報告されるエラーは無視して安全です。

  1. シードノードで、偽のスロットをポイントしてメタデータを安全に更新します。

ALTER SUBSCRIPTION migration_seed_sub SET (slot_name = bogus);

  1. パブリケーションを有効にして更新します。

ALTER SUBSCRIPTION migration_seed_sub ENABLE;
ALTER SUBSCRIPTION migration_seed_sub REFRESH PUBLICATION WITH (copy_data = false);
ALTER SUBSCRIPTION migration_seed_sub DISABLE;

  1. サブスクリプションのテーブルリストが シードノードへの論理レプリケーションの有効化 で取得した構成と一致することを確認します。

SELECT n.nspname AS schemaname,
    c.relname AS tablename,
    sr.srsubstate AS state,
    s.subname AS subscription_name
FROM pg_subscription_rel sr
JOIN pg_class c ON sr.srrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
JOIN pg_subscription s ON sr.srsubid = s.oid
WHERE s.subname = migration_seed_sub
ORDER BY n.nspname, c.relname;

  1. サブスクリプションを正しいスロットに戻し、適切なLSNでレプリケーションを再開します。

ALTER SUBSCRIPTION migration_seed_sub
    SET (slot_name = migration_node_${SEED_NODE_NAME});
ALTER SUBSCRIPTION migration_seed_sub ENABLE;

この段階で、シードノードは新しいPostgresバージョンを実行し、ソースプライマリから論理更新を受信しています。 PGDの初期化に進む前に、システムが安定するまで待ち、シードノードが完全に追いついたことを確認します。

次のステップ Initializing PGD 。

目次