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

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

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

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

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

アップグレードの準備#

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

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

sudo -u postgres pgd show-nodes

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

sudo -u postgres pgd show-groups

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

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

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

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

注釈

データの損失を防ぐため、アップグレードプロセスを開始する前にデータベースと構成ファイルがバックアップされていることを確認してください。

preliminary order を使用して、SSH経由で接続しているときに各ノードで次の手順を実行します。

現在のPostgresバージョンの確認
sudo -u postgres pgd show-version .
を実行してPGDからバージョンを表示します予想されるメジャーバージョンが実行されていることを確認します。
ターゲットノードが書き込みリーダーでないことを確認します
sudo -u postgres pgd show-groups .
を使用して、アップグレードしているグループの書き込みリーダーであるかどうかを確認します。ターゲットノードがグループの現在の書き込みリーダーの場合/アップグレードするサブグループ、別のノードに対して計画的なスイッチオーバーを実行するを実行します。
- sudo -u postgres pgd switchover --group-name <group_name> --node-name <new_write_leader_node_name>
ターゲットノードでPostgresを停止します
sudo systemctl stop postgres .
を実行して、現在のノードで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 コマンドの使用が含まれます。
<path_to_postgres_bin> を、新しくインストールしたPostgreSQLバージョンのbinディレクトリへのパスに置き換えます。sudo -u postgres <path_to_postgres_bin>/initdb -D /opt/postgres/datanew .
postgresユーザーまたは適切な権限を持つ別のユーザーとしてこのコマンドを実行する必要があります。
クラスターが確実に動作するように--data-checksums フラグを含めてくださいデータのチェックサムを使用します。
新しいPostgresバージョンに構成を移行する
現在のPostgreSQLデータディレクトリで次の構成ファイルを見つけます。
postgresql.conf - データベースシステムに関連する設定を含むメイン構成ファイル。
postgresql.auto.conf - 次のようなPostgreSQLによって設定された設定が含まれています。 ALTER SYSTEM コマンドで変更します
pg_hba.conf - クライアント認証を管理し、どのユーザーがどのホストからどのデータベースに接続できるかを指定します。
conf.d ディレクトリ全体 - 構成設定を別のファイルに整理して管理しやすくします。
これらのファイルをコピーしますおよび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 によって作成されたアップグレードログファイルを保存できるように、bdr_pg_upgrade によって作成されたアップグレードログファイルを保存できます。
安全性チェックを開始するには、bdr_pg_upgrade コマンドに--check オプションを追加します。
この操作は、変更を加えずにアップグレードプロセスをシミュレートします。、互換性の問題、非推奨の機能、またはアップグレードの成功に必要な構成調整に関する洞察を提供します。
このチェックで示された警告またはエラーに対処して、新しいバージョンへのスムーズな移行を保証します。
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バージョンを検証する - 再度sudo -u postgres pgd show-version を実行して、PostgreSQLインスタンスがアップグレードされたことを確認します。
アップグレード後のクリーンアップ
アップグレードの直後、高い運用負荷を導入する前に、 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クラスターを再展開します - tpaexec deploy <cluster_name>

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

実際の例#

この実用的な例は、 AWS Quickstart を使用して展開されたTPA管理のPGDクラスターから始まります。クラスターには、kaboom、kaolin、およびkaftanの3つのノードがあり、すべてPostges 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サービスが非アクティブであることを確認します#

previously stopped the Postgres service on the target node 、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

Postgresのメジャーバージョンのアップグレードを実行します#

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

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の新しいバージョンのリコンシリエーション、およびアップグレード手順全体が完了しました。

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

目次

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

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

アップグレードの準備#

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

実際の例#

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

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

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

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

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

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

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

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

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

アップグレードの実現可能性を確認する#

Postgresのメジャーバージョンのアップグレードを実行します#

Postgresサービス構成の更新#

Postgresを再起動します#

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

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

次のステップ#

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

TPAとの調整#