Performing a Postgres major version rolling upgrade on a PGD cluster built with TPA#

Postgresメジャーバージョンのアップグレード#

Postgresデータベースのメジャーバージョンをアップグレードして、改善された機能、パフォーマンス強化、およびセキュリティ更新にアクセスすることは、一般的な管理タスクです。 Trusted Postgres ArchitectTPAで展開されたEDB Postgres DistributedPGDクラスターに対して同じことを行うことは、基本的に同じプロセスですが、ローリングアップグレードとして実行されます。

ローリングアップグレードプロセスにより、クラスターの可用性と操作の継続性を維持しながら、個々のクラスターノードを新しいメジャーPostgresバージョンに更新できます。このアプローチでは、各ノードがシークエンシャルにアップグレードされるときに、クラスターの残りの部分を操作可能なままにすることにより、ダウンタイムを最小限に抑え、データの整合性を保証します。

次の一般的な手順の概要と実際の例は、スムーズで制御されたアップグレードプロセスを提供するのに役立ちます。

アップグレードの準備#

アップグレードの準備をするには、アップグレードしようとしているサブグループとノードを特定し、最初のアップグレード順序をメモします。

これを行うには、SSHを使用してノードのいずれかに接続し、 pgd show-nodes コマンドを実行します。

sudo -u postgres pgd show-nodes

pgd show-nodes コマンドは、PGDクラスター内のすべてのノードと、各ノードが属しているサブグループを表示します。次に、各サブグループの書き込みリーダーであるノードを見つけます。

sudo -u postgres pgd show-groups

このコマンドは、クラスターで実行されているさまざまなグループ/サブグループのリストと、各グループの書き込みリーダーを出力します。操作の継続性を維持するには、書き込みリーダーをアップグレードする前に、サブグループ内の別のノードにスイッチする必要があります。計画的なスイッチオーバーの数を最小限に抑えるには、ノードのサブグループをアップグレードするときに、最後にライタリーダーをアップグレードします。

計画のためにどのノードが現在の書き込みリーダーであるかを確認した場合でも、サブグループの書き込みリーダーは、そのノードをアップグレードする前に、操作上の理由でいつでも別のノードに変更される可能性があります。したがって、ノードをアップグレードする前に、ノードが書き込みリーダーでないことを確認する必要があります。

これで、各サブグループで最後に指定された書き込みリーダーノードをアップグレードすることを目的として、一度に1サブグループごとにアップグレード順序を決定するための十分な情報が得られました。

各ノードでアップグレードを実行する#

注釈

データの損失を防ぐため、アップグレードプロセスを開始する前に、データベースと構成ファイルがバックアップされていることを確認してください。アップグレードの準備を使用して、SSH経由で接続しているときに各ノードで次の手順を実行します。

現在のPostgresバージョンを確認します * PGDからバージョンを表示します。

sudo -u postgres pgd show-version . * 予想されるメジャーバージョンが実行されていることを確認します。

ターゲットノードが書き込みリーダーでないことを確認します *ターゲットノードがアップグレードするグループの書き込みリーダーであるかどうかを確認します。

sudo -u postgres pgd show-groups *ターゲットノードが、アップグレードするグループ/サブグループの現在の書き込みリーダーである場合、別のノードに対して計画的なスイッチオーバーを実行するを実行します。

sudo -u postgres pgd switchover --group-name <group_name> --node-name <new_write_leader_node_name>

ターゲットノードでPostgresを停止します *現在のノードでPostgresサービスを停止します。

sudo systemctl stop postgres

ターゲットノードは、クラスター内のノードとしてアクティブに参加していません。

PGDとユーティリティのインストール * アップグレード先のPostgresバージョンと互換性のあるPGDとそのユーティリティをインストールします。

sudo apt install edb-bdr<new_pgd_version_number>-pg<new_postgres_version_number> edb-bdr-utilities

新しいPostgresインスタンスを初期化します *新しいバージョンのPostgreSQLのデータベースファイルを格納するディレクトリを作成します。

sudo mkdir -p /opt/postgres/datanew ユーザーpostgresが``chown`` を使用してディレクトリへの所有権権限があることを確認します。 作成したディレクトリで新しいPostgreSQLデータベースクラスターを初期化します。この手順には、PostgreSQLの新しくインストールされたバージョンが提供するinitdb コマンドの使用が含まれます。 --data-checksums フラグを含めて、クラスターがデータチェックサムを使用するようにします。

sudo -u postgres <path_to_postgres_bin>/initdb -D /opt/postgres/datanew --data-checksums

<path_to_postgres_bin> を、新しくインストールされたPostgreSQLバージョンのbinディレクトリへのパスに置き換えます。

このコマンドは、 postgresユーザーまたは適切な権限を持つ別のユーザーとして実行する必要がある場合があります。

構成を新しいPostgresバージョンに移行する 現在のPostgreSQLデータディレクトリで次の構成ファイルを見つけます。 postgresql.conf —データベースシステムに関連する設定を含むメイン構成ファイル。 ``postgresql.auto.conf`` — ``ALTER SYSTEM`` コマンドで変更した設定など、PostgreSQLによって設定された設定が含まれています。 pg_hba.conf —クライアント認証を管理し、どのユーザーがどのホストからどのデータベースに接続できるかを指定します。 ``conf.d`` ディレクトリ全体存在する場合 - mdash;構成設定を別のファイルに整理して、管理しやすくします。 これらのファイルとconf.d ディレクトリを、PostgreSQLのアップグレードバージョン用に作成した新しいデータディレクトリにコピーします。
Postgresサービスが非アクティブであることを確認します *続行する前に、古いデータディレクトリと新しいデータディレクトリの両方でアクティブなPostgreSQLプロセスがないことを確認することが重要です。この検証手順により、アップグレードプロセス中のデータの破損または競合が防止されます。

sudo systemctl status postgres コマンドを使用して、Postgresが停止したことを確認します。停止していない場合は、 systemctl stop postgres を実行して、停止されたことを再度確認します。

バージョンアップグレードのPGDATAディレクトリをスワップします * /opt/postgres/data を/opt/postgres/dataold に、/opt/postgres/datanew を/opt/postgres/data に名前変更します。

この手順により、システムは次の重要なフェーズ、 pg_upgradeを実行してPostgreSQLバージョンの移行を仕上げる準備が整います。

アップグレードの実現可能性を確認する * bdr_pg_upgrade ツールは、現在のセットアップの予備スキャンを実行し、アップグレードプロセスを妨げる可能性のある潜在的な問題を特定するように設計された--check オプションを提供します。

bdr_pg_upgrade によって作成されたアップグレードログファイルを保存できるように、/home/upgrade/ などのユーザーpostgresに所有権が付与されたアップグレードディレクトリからこのチェックを実行する必要があります。安全性チェックを開始するには、 --check オプションをbdr_pg_upgrade コマンドに追加します。

この操作は、変更を加えずにアップグレードプロセスをシミュレートし、互換性問題、非推奨機能、またはアップグレードの成功に必要な構成調整に関する洞察を提供します。 *このチェックで示された警告またはエラーに対処して、新しいバージョンへのスムーズな移行を保証します。

Postgresメジャーバージョンのアップグレードを実行します ``--check`` オプションを指定せずに``bdr_pg_upgrade`` コマンドを実行して、アップグレードプロセスを実行します。 注意が必要なエラーまたは警告がないかコマンド出力を監視することが重要です。 *アップグレードプロセスにかかる時間は、データベースのサイズとセットアップの複雑さによって異なります。
Postgresサービス構成の更新 * postgres.service ファイルのバージョン番号を更新することにより、新しいPostgreSQLバージョンを反映するようにサービス構成を更新します。

sudo sed -i -e 's/<old_version_number>/<new_version_number>/g' /etc/systemd/system/postgres.service *システムのサービスマネージャーを更新して、これらの変更を適用します。

sudo systemctl daemon-reload

Postgresを再起動します * PostgreSQLサービスの再起動に進みます。

systemctl start postgres

新しいPostgresバージョンを検証する * PostgreSQLインスタンスがアップグレードされたことを確認します。

sudo -u postgres pgd show-version

アップグレード後のクリーンアップ アップグレードの直後、高い運用負荷を導入する前に、 ``ANALYZE`` オプションを使用して``vacuumdb`` を実行します。このコマンドを実行すると、即時のパフォーマンスへの影響が最小限に抑えられ、より正確なテストのためにデータベースが準備されます。古いバージョンのデータディレクトリ/opt/postgres/dataold を削除します。

TPAでアップグレードを調整する#

TPAは、すべてのノードがアップグレードされた後、展開を効果的に管理し続ける必要があります。したがって、アップグレードされたノードをTPAと調整する必要があります。

次の手順に従って、TPAを介して構成を更新し、PGDクラスターを再展開します。

``config.yml`` の更新 * TPA管理対象クラスターのconfig.yml を新しいバージョンに変更します。

cluster_vars: postgres_version: '<new_version_number>'

``tpaexec`` を使用して、更新された``config.yml`` でPGDクラスターを再展開します *これはdeploy オプションを使用します tpaexec deploy <cluster_name>

次の作業例では、TPAで展開されたPGD 5クラスターでのPostgresメジャーバージョン15から16へのアップグレードを詳細に示しています。

実際の例#

この実用的な例は、 Deploying an EDB Postgres Distributed example cluster on AWS を使用して展開されたTPA管理のPGDクラスターから始まります。クラスターには、kaboom、kaolin、およびkaftanの3つのノードがあり、すべてPostgres 15を実行しています。

この例はkaboomで始まります。

注釈

このプロセスの一部の手順には、Postgres所有者としてコマンドを実行することが含まれます。必要に応じて、このユーザーをpostgresと呼びます。 EDB Postgres Advanced Serverを実行している場合、関連するすべてのコマンドでpostgresユーザーをenterprisedbに置き換えます。

現在のPostgresバージョンの確認#

kaboomにSSHで接続して、Postgresのメジャーバージョンが予想されることを確認します。

sudo -u postgres pgd show-version

クラスターの出力はこれに似ています。

Node   BDR Version Postgres Version
- ---   ----------- ----------------
kaboom 5.4.0       15.6 (Debian 15.6-2EDB.buster)
kaftan 5.4.0       15.6 (Debian 15.6-2EDB.buster)
kaolin 5.4.0       15.6 (Debian 15.6-2EDB.buster)

Postgresバージョンが予想されるバージョンであることを確認します。

ターゲットノードが書き込みリーダーでないことを確認する#

クラスターは、プロセス全体つまり ローリング アップグレード全体で利用できる必要があります。継続的なクラスターの可用性を維持するには、常に使用可能な書き込みリーダーが必要です。したがって、ターゲットノードが現在の書き込みリーダーである場合、書き込みリーダーが常に利用できるように、アップグレードする前に書き込みリーダーを見つけるノードの計画的なスイッチオーバーを実行するを行う必要があります。

SSHを介してkaboomに接続しているときに、 pgd show-groups コマンドを使用して、アップグレードしているグループの現在の書き込みリーダーがどのノードであるかを確認します。

sudo -u postgres pgd show-groups

この場合、kaboomが唯一のサブグループdc1_subgroup の現在の書き込みリーダーであることがわかります。

Group        Group ID   Type   Parent Group Location Raft Routing Write Leader
- ----        --------   ----   ------------ -------- ---- ------- ------------
democluster  1935823863 global                       true false
dc1_subgroup 1302278103 data   democluster  dc1      true true    kaboom

したがって、 dc1_subgroup の書き込みリーダーのクラスター内の別のノードへの計画的なスイッチオーバーを実行する必要があります。

計画的なスイッチオーバーを実行する#

書き込みリーダーをkaftanに変更して、kaboomのPostgresインスタンスを停止できるようにします。

sudo -u postgres pgd switchover --group-name dc1_subgroup --node-name kaftan

スイッチオーバーが成功した後、ターゲットノードでPostgresを停止しても安全です。もちろん、アップグレードするときにkaftanがまだ書き込みリーダーである場合、その時点で別の計画的なスイッチオーバーを実行する必要があります。

ターゲットノードでPostgresを停止します#

SSHを介してターゲットノードこの場合kaboomに接続しているときに、次のコマンドを実行してノードでPostgresを停止します。

sudo systemctl stop postgres

このコマンドは、kaboomでサーバーを停止します。クラスターは、他の2つのノードを使用して実行を継続します。

PGDとユーティリティのインストール#

次に、Postgresの新しいバージョンPG16とアップグレードツールをインストールします。

sudo apt install edb-bdr5-pg16 edb-bdr-utilities

新しいPostgresインスタンスを初期化する#

アップグレードされたPostgresの新しいデータディレクトリを作成し、postgresユーザーにディレクトリの所有権を付与します。

sudo mkdir /opt/postgres/datanew
sudo chown -R postgres:postgres /opt/postgres/datanew

次に、新しいディレクトリでPostgres 16を初期化します。

sudo -u postgres /usr/lib/postgresql/16/bin/initdb \
  -D /opt/postgres/datanew \
  -E UTF8 \
  --lc-collate=en_US.UTF-8 \
  --lc-ctype=en_US.UTF-8 \
  --data-checksums

このコマンドは、構成用のPG16データディレクトリ /opt/postgres/datanew を作成します。

構成を新しいPostgresバージョンに移行する#

次のステップでは、構成ファイルを古いPostgresバージョンPG15から新しいPostgresバージョンのPG16にコピーします。構成ファイルは、各バージョンのデータディレクトリにあります。

postgresql.conf 、postgresql.auto.conf 、およびpg_hba.conf ファイルとconf.d ディレクトリ全体をコピーします。

sudo -u postgres cp /opt/postgres/data/postgresql.conf /opt/postgres/datanew/
sudo -u postgres cp /opt/postgres/data/postgresql.auto.conf /opt/postgres/datanew/
sudo -u postgres cp /opt/postgres/data/pg_hba.conf /opt/postgres/datanew/
sudo -u postgres cp -r /opt/postgres/data/conf.d/ /opt/postgres/datanew/

Postgresサービスが非アクティブであることを確認します#

ターゲットノードでPostgresを停止します、kaboomですが、停止したことを確認するには、 systemctl status postgres コマンドを実行します。

sudo systemctl status postgres

status コマンドの出力は、Postgresサービスが実行を停止したことを示しています。

● postgres.service - Postgres 15 (TPA)
   Loaded: loaded (/etc/systemd/system/postgres.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Wed 2024-03-20 15:32:18 UTC; 4min 9s ago
 Main PID: 24396 (code=exited, status=0/SUCCESS)

Mar 20 15:32:18 kaboom postgres[25032]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.89(20108)/[unknown]/bdrdb:25032]: [1] FA
Mar 20 15:32:18 kaboom postgres[25033]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.89(20124)/[unknown]/bdrdb:25033]: [1] FA
Mar 20 15:32:18 kaboom postgres[25034]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.88(43534)/[unknown]/bdrdb:25034]: [1] FA
Mar 20 15:32:18 kaboom postgres[25035]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.88(43538)/[unknown]/bdrdb:25035]: [1] FA
Mar 20 15:32:18 kaboom postgres[25036]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.87(37292)/[unknown]/bdrdb:25036]: [1] FA
Mar 20 15:32:18 kaboom postgres[25037]: [22-1] 2024-03-20 15:32:18 UTC [pgdproxy@10.33.125.87(37308)/[unknown]/bdrdb:25037]: [1] FA
Mar 20 15:32:18 kaboom postgres[24398]: [24-1] 2024-03-20 15:32:18 UTC [@//:24398]: [15] LOG:  checkpoint complete: wrote 394 buffe
Mar 20 15:32:18 kaboom postgres[24396]: [22-1] 2024-03-20 15:32:18 UTC [@//:24396]: [23] LOG:  database system is shut down
Mar 20 15:32:18 kaboom systemd[1]: postgres.service: Succeeded.
Mar 20 15:32:18 kaboom systemd[1]: Stopped Postgres 15 (TPA).

バージョンアップグレードのためにPGDATAディレクトリをスワップする#

次に、 PG15およびPG16データディレクトリを交換します。

sudo mv /opt/postgres/data /opt/postgres/dataold
sudo mv /opt/postgres/datanew /opt/postgres/data

重要

プロシージャー中のある時点で何かが発生した場合、ノードを古いメジャーバージョンにロールバック/戻すことができます。これを行うには、ディレクトリの名前を再度変更して、現在のデータディレクトリ /opt/postgres/data が`/opt/postgres/datafailed` になり、古いデータディレクトリ /opt/postgres/dataold が現在のデータディレクトリになるようにします。

sudo mv /opt/postgres/data /opt/postgres/datafailed
sudo mv /opt/postgres/dataold /opt/postgres/data

これにより、ノードがPostgresの以前のメジャーバージョンにロールバック/元に戻ります。

bdr_pg_upgrade ツールには、アップグレードプロセスの一部のドライランを実行する--check オプションがあります。このオプションを使用して、アップグレードをスムーズに行うことができます。

ただし、最初に、bdr_pg_upgrade によって作成されたファイルのディレクトリが必要です。この例では、 /home ディレクトリに/upgrade ディレクトリを作成します。次に、ディレクトリの所有権をユーザーpostgresに付与します。

sudo mkdir /home/upgrade
sudo chown postgres:postgres /home/upgrade

次に、 /home/upgrade に移動して、実行します。

sudo -u postgres /usr/bin/bdr_pg_upgrade \
  --old-bindir /usr/lib/postgresql/15/bin/ \
  --new-bindir /usr/lib/postgresql/16/bin/ \
  --old-datadir /opt/postgres/dataold/ \
  --new-datadir /opt/postgres/data/ \
  --database bdrdb \
  --check

以下は出力です。

Performing BDR Postgres Checks
- -----------------------------
Collecting pre-upgrade new cluster control data             ok
Checking new cluster state is shutdown                      ok
Checking BDR versions                                       ok

Passed all bdr_pg_upgrade checks, now calling pg_upgrade

Performing Consistency Checks
- ----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible

注釈

--data-checksums オプションを使用してチェックサムでPostgres 16を初期化せず、Postgres 15インスタンスでチェックサムを初期化した場合、エラーは非互換性について示します。

old cluster uses data checksums but the new one does not

アップグレードを実行する準備が整いました。ターゲットノードで、次を実行します。

sudo -u postgres /usr/bin/bdr_pg_upgrade \
  --old-bindir /usr/lib/postgresql/15/bin/ \
  --new-bindir /usr/lib/postgresql/16/bin/ \
  --old-datadir /opt/postgres/dataold/ \
  --new-datadir /opt/postgres/data/ \
  --database bdrdb

以下は予想される出力です。

Performing BDR Postgres Checks
- -----------------------------
Collecting pre-upgrade new cluster control data             ok
Checking new cluster state is shutdown                      ok
Checking BDR versions                                       ok
Starting old cluster (if shutdown)                          ok
Connecting to old cluster                                   ok
Checking if bdr schema exists                               ok
Turning DDL replication off                                 ok
Terminating connections to database                         ok
Disabling connections to database                           ok
Waiting for all slots to be flushed                         ok
Disconnecting from old cluster                              ok
Stopping old cluster                                        ok
Starting old cluster with BDR disabled                      ok
Connecting to old cluster                                   ok
Collecting replication origins                              ok
Collecting replication slots                                ok
Disconnecting from old cluster                              ok
Stopping old cluster                                        ok

Passed all bdr_pg_upgrade checks, now calling pg_upgrade

Performing Consistency Checks
- ----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Creating dump of global objects                             ok
Creating dump of database schemas                           ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
- -----------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_xact to new server                           ok
Setting oldest XID for new cluster                          ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster               ok
Copying user relation files                                 ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to delete old cluster                       ok
Checking for extension updates                              notice

Your installation contains extensions that should be updated
with the ALTER EXTENSION command.  The file
    update_extensions.sql
when executed by psql by the database superuser will update
these extensions.

Upgrade Complete
- ---------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
    /usr/pgsql-15/bin/vacuumdb --all --analyze-in-stages

Running this script will delete the old clusters data files:
    ./delete_old_cluster.sh

pg_upgrade complete, performing BDR post-upgrade steps
- -----------------------------------------------------
Collecting old cluster control data                         ok
Collecting new cluster control data                         ok
Checking LSN of new cluster                                 ok
Starting new cluster with BDR disabled                      ok
Connecting to new cluster                                   ok
Creating replication origin (bdr_bdrdb_rb69_bdr2)           ok
Advancing replication origin (bdr_bdrdb_rb69_bdr2, 0/1F4... ok
Creating replication origin (bdr_bdrdb_rb69_bdr1)           ok
Advancing replication origin (bdr_bdrdb_rb69_bdr1, 0/1E8... ok
Creating replication slot (bdr_bdrdb_rb69_bdr1)             ok
Creating replication slot (bdr_bdrdb_rb69)                  ok
Creating replication slot (bdr_bdrdb_rb69_bdr2)             ok
Stopping new cluster

Postgresサービス構成の更新#

システム上のPostgresサービスは、古いバージョンのPostgres PG15を起動するように構成されています。新しいバージョンPG16をスタートするには、postgres.service ファイルを変更する必要があります。

sed を使用して、ファイル全体で古いバージョン番号15 を16 に置き換えます。

sudo sed -i -e  s/15/16/g /etc/systemd/system/postgres.service

バージョン番号を変更した後、systemdデーモンに構成をリロードするように指示できます。ターゲットノードで、次を実行します。

sudo systemctl daemon-reload

Postgresを再起動します#

変更したPostgresサービスを開始します。

sudo systemctl start postgres

新しいPostgresバージョンを検証する#

最初の手順を繰り返し、Postgresのバージョンを確認して、kaboomを正しくアップグレードしたことを確認します。まだkaboom上で、次を実行します。

sudo -u postgres pgd show-version

出力を使用して、kaboomがアップグレードされたPostgresバージョンを実行していることを確認します。

Node   BDR Version Postgres Version
- ---   ----------- ----------------
kaboom 5.4.0       16.2 (Debian 16.2-2EDB.buster)
kaftan 5.4.0       15.6 (Debian 15.6-2EDB.buster)
kaolin 5.4.0       15.6 (Debian 15.6-2EDB.buster)

ここで、kaboomはメジャーバージョン16にアップグレードされました。

アップグレード後のクリーンアップ#

ベストプラクティスとして、この時点でデータベースにバキュームを実行します。アップグレードが実行されると、アップグレード後レポートに次のものが含まれていることに気づいたかもしれません。

Once you start the new server, consider running:
    /usr/lib/postgresql/16/bin/vacuumdb --all --analyze-in-stages

これで、バキュームを実行できます。ターゲットノードで、次を実行します。

sudo -u postgres /usr/lib/postgresql/16/bin/vacuumdb --all --analyze-in-stages

このノードを元に戻す必要がない場合は、古いデータディレクトリフォルダーdataold をクリーンアップすることもできます。

sudo rm -r /opt/postgres/dataold

これでターゲットノードのアップグレードが完了しました。

次のステップ#

kaboomでのアップグレードが完了した後、kaolinとkaftanで同じ手順を実行します。

この例に従い、kaftanが書き込みリーダーである場合、可用性を保証には、kaftanでアップグレード手順を実行する前に、既にアップグレードされた別のノードに計画的なスイッチオーバーを実行するを実行する必要があります。

クラスター全体のPostgresバージョンを確認する#

すべてのノードでアップグレードが完了した後、ノードのいずれかに接続しているときに、バージョンを再度確認できます。

sudo -u postgres pgd show-version

出力は次のようなものになります。

Node   BDR Version Postgres Version
- ---   ----------- ----------------
kaboom 5.4.0       16.2 (Debian 16.2-2EDB.buster)
kaftan 5.4.0       16.2 (Debian 16.2-2EDB.buster)
kaolin 5.4.0       16.2 (Debian 16.2-2EDB.buster)

この出力は、すべてのノードが新しいPostgresバージョン16に正常にアップグレードされたことを示しています。

TPAとの調整#

すべてのノードがアップグレードされた後、TPAを使用してPostgresのアップグレードバージョンを reconcile して、将来的にTPAを使用してクラスターを管理し続けられるようにする必要があります。

これを行うには、TPAクラスターディレクトリが存在するコマンドラインに戻ります。この作業した例では、TPAクラスターディレクトリは、TPAを使用してクラスターを最初にデプロイしたインスタンスの/home/ubuntu/democluster です。

クラスターディレクトリに移動した後、コードエディタを使用してconfig.yml を編集し、 cluster_vars: をpostgres_version: '15' からpostgres_version: '16' に変更します。

.bashrc または.bash_profile にまだ追加されていない限り、 TPAのバイナリディレクトリをPATHに追加することにより、コマンドラインセッションでTPAツールにアクセスできることを確認します。

export PATH=$PATH:/opt/EDB/TPA/bin

最後に、クラスターを再展開します。

tpaexec deploy democluster

このコマンドは、TPAによって管理されるクラスターに構成変更を適用します。展開が成功した場合、TPAとPostgresの新しいバージョンのリコンシリエーション、およびアップグレード手順全体が完了しました。