Performing a Postgres major version rolling upgrade on a PGD cluster#

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

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

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

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

アップグレードの準備#

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

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

sudo -u postgres pgd nodes list

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

sudo -u postgres pgd group <group_name> show --summary

このコマンドは、クラスターで実行されている<group_name> によってトークン化されたpgdグループに関する情報を表示します。どのノードが書き込みリーダーであるかなど。操作の継続性を維持するには、書き込みリーダーをアップグレードする前に、サブグループ内の別のノードにスイッチする必要があります。計画的なスイッチオーバーの数を最小限に抑えるには、ノードのサブグループをアップグレードするときに、最後にライタリーダーをアップグレードします。

アップグレードが完了するまで、アップグレードされるノードが書き込みリーダーにならないように、アップグレードを開始する前にノードをフェンスし、ノードのアップグレードが完了した後にノードのフェンスを解除する必要があります。

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

注釈

Postgresクライアントツールを実行するが、PGDデータノードを実行しないノードは、 Postgresクライアントライブラリを使用します。 PGDデータノードをアップグレードする前に、これらのノードを新しいメジャーバージョンの`edb-as<xx>-server-client` EPASまたは`postgresql-client-<xx>` PGパッケージにアップグレードします。

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

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

重要

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

アップグレードの準備を使用して、SSH経由で接続しているときに各ノードで次の手順を実行します。

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

sudo -u postgres pgd nodes list --versions .

予想されるメジャーバージョンが実行されていることを確認します。
ターゲットノードが書き込みリーダーでないことを確認します
ターゲットノードがアップグレードするグループの書き込みリーダーであるかどうかを確認します。

sudo -u postgres pgd group <group_name> show --summary

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

sudo -u postgres pgd group <group_name> set-leader <new_leader_node_name>

ノードをフェンスする
アップグレードが完了するまで、アップグレードされるノードが書き込みリーダーにならないように、アップグレードを開始する前にノードをフェンスする必要があります。
ターゲットノードでPostgresを停止します
現在のノードでPostgresサービスを停止します。

sudo systemctl stop postgres

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

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

sudo apt install edb-pgd6-expanded-pg<new_postgres_version_number>

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

sudo mkdir -p /opt/postgres/datanew

chown .
を使用してユーザーpostgresにディレクトリへの所有権権限があることを確認します。作成したディレクトリで新しい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 -などの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 に名前変更します。

この手順により、システムは次の重要なフェーズ、pgdノードのアップグレードを実行してPostgreSQLバージョンの移行を完了するための準備が整います。

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

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

この操作は、変更を加えずにアップグレードプロセスをシミュレートし、互換性の問題、非推奨機能、またはアップグレードの成功に必要な構成調整に関する洞察を提供します。

このチェックで示された警告またはエラーに対処して、新しいバージョンへの平穏な移行を保証します。
Postgresメジャーバージョンのアップグレードを実行します
--check オプションを指定せずにpgd node <node_name> 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 nodes list --versions

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

実際の例 PGD 4からPGD 6へのアップグレード#

この作業した例では、PGD 4からPGDバージョン6.4へのインプレースメジャーバージョンのローリングアップグレードについて説明します。

概要#

HARPプロキシベースのルーティングを使用するPGD 4クラスターは、クラスター全体がバージョン6.4.0以降にアップグレードされるまで、すべてのノードにこのルーティング方法を継続します。 HARPプロキシベースのルーティングは、混合バージョンクラスター内で同じように機能します。 4.xクラスターには書き込みリーダーがないため、 HARPは独自のメカニズムを使用してリーダーを選択します。クラスター全体がバージョン6.4.0以降にアップグレードされると、接続マネージャーは既に有効になっており、準備が整います。アプリケーションは接続マネージャーポート/ノードを指すことができ、ルーティングを開始します。動作していることが確認されたら、プロキシを停止できます。

注釈

この例では、 PGDアーキテクチャで推奨されているように、 HarpプロキシがPGDノードと同じ場所にないことを前提としています。 PGDノードと同じ場所にHarpプロキシがある場合、アップグレード手順についてはEDBサポートに連絡してください。

harp-プロキシリーダーの確認#

harp-プロキシリーダーではないノードでアップグレードを開始します。どのノードがharpプロキシリーダーであるかを確認します。

test-pgd6major-d1:~ $ harpctl get leader a

Cluster  Name                     Location Ready Fenced Allow Routing Routing Status Role    Type Lock Duration
- ------  ----                     -------- ----- ------ ------------- -------------- ----    ---- -------------
bdrgroup test-pgd6major-d2 a        true  false  true                         primary bdr  6

ノードをフェンスする#

HARPからアップグレードするノードをフェンスオフし、フェンスされたことを確認して、アップグレードの途中でリーダーにならないようにします。

test-pgd6major-d1:~ $ harpctl fence test-pgd6major-d1

INFO    cmd/fence.go:42 fence node test-pgd6major-d1

test-pgd6major-d1:~ $ harpctl get nodes
Cluster  Name                     Location Ready Fenced Allow Routing Routing Status Role    Type Lock Duration
- ------  ----                     -------- ----- ------ ------------- -------------- ----    ---- -------------
bdrgroup test-pgd6major-d1 a        false true   true          N/A            primary bdr  6
bdrgroup test-pgd6major-d2 a        true  false  true          ok             primary bdr  6

Postgresサービスを停止します#

フェンスされたノードで、Postgresサービスを停止します。

HARPマネージャーを停止します#

フェンスされたノードで、 HARPマネージャーを停止します。

パッケージの削除とインストール#

フェンスされたノードで、 PGD 4.4およびcliパッケージを削除し、 PGDバージョン6.4パッケージをインストールします。

Postgresサービスを開始する#

フェンスされたノードで、Postgresサービスを開始します。これにより、接続マネージャーが有効になっている状態でPGDローカルノードのPGDバージョン6.4へのインプレースアップグレードが実行されます。

HARPマネージャーをスタートする#

フェンスされたノードで、 HARPマネージャーを起動します。

ノードのフェンスを解除する#

アップグレードされたノードのフェンシングをHARPから解除します。

test-pgd6major-d1:~ $ harpctl unfence test-pgd6major-d1

すべてのノードに対して手順を繰り返します。#

他のすべてのノードで同じ手順を繰り返します。

クラスターバージョンの確認#

bdr.group_raft_details を実行して、更新されたクラスターバージョンがバージョン6001であることを確認します。

SCRAMハッシュの確認#

アップグレードノードから次のクエリーを実行して、SCRAMハッシュが各ユーザーのすべてのノードで同じであることを確認します。これは、アプリケーションが接続マネージャーに切り替える前に必要です。

DO $$
DECLARE
    rec RECORD;
    command TEXT;
BEGIN
    FOR rec IN SELECT rolname,rolpassword FROM pg_authid WHERE rolcanlogin = true AND rolpassword like SCRAM-SHA%
    LOOP
        command := ALTER ROLE  || quote_ident(rec.rolname) ||  WITH ENCRYPTED PASSWORD  ||  || rec.rolpassword || ;
        EXECUTE command;
    END LOOP;
END;
$$;
SELECT bdr.wait_slot_confirm_lsn(NULL,NULL);

ルーティングを有効にする#

グローバルまたはローカルルーティング要件に従って、ノードグループルーティングを有効にします。ローカルルーティングの場合はサブグループで有効にし、グローバルルーティングの場合はトップグループで有効にします。

bdrdb=# SELECT bdr.alter_node_group_option(node_group_name := bdrgroup,config_key := enable_routing, config_value := true::TEXT);

出力

 alter_node_group_option
- ------------------------
 (1 row)

接続マネージャーに切り替える#

これで、アプリケーションをConnection Managerに安全に切り替えられるはずです。

harpマネージャーとプロキシサービスを停止します。#

これで、実行中のharpマネージャーとプロキシサービスを安全に停止できるはずです。

注釈

これで、PGD 4からPGDバージョン6.4へのインプレースメジャーバージョンのローリングアップグレードの作業例が完了しました。

実際の例 PGD 5からPGD 6へのアップグレード#

この例では、 pgd node upgrade コマンドを使用して、3ノードPGD 5、EPAS 13クラスターからPGDバージョン6.4、EPAS 17クラスターへのインプレースメジャーバージョンローリングアップグレードPGD & Postgresについて説明します。

前提条件#

3ノードPGD 5、EPAS 13クラスターが稼働していることを確認します。これは、TPA展開されたクラスターです。

pgd-a1:/home/rocky $ pgd nodes list

出力

Node Name  Group Name Node Kind Join State Node Status
- --------- ---------- --------- ---------- -----------
pgd-a1     group-a    data      ACTIVE     Up
pgd-a2     group-a    data      ACTIVE     Up
witness-a1 group-a    witness   ACTIVE     Up

新しいサーバーとPGDのパッケージをインストールします#

EPAS 17のパッケージと、対応するPGD 6パッケージがクラスター内のすべてのノードにインストールされていることを確認します。バイナリの競合を防ぐには、 PGD 6パッケージをインストールする前に、PGD 5パッケージつまりedb-pgd5-cliおよびedb-bdr5-epas13を削除する必要があります。以下のコマンドは、RHEL 8プラットフォームで使用されました。特定のプラットフォームに適切なコマンドを使用します。

dnf remove edb-pgd5-cli
dnf install edb-as17-server edb-pgd6-expanded-epas17 -y

アップグレード前の手順#

バージョンチェック#

クラスターの現在のバージョンを確認しますオプショナル。

pgd-a1:/home/rocky $ pgd nodes list --versions

出力

Node Name  BDR Version  Postgres Version
- --------- ------------ ----------------
pgd-a1     5.9.0        13.22.28
pgd-a2     5.9.0        13.22.28
witness-a1 5.9.0        13.22.28

接続マネージャーに移動#

PGD 5は、ルーティングにPGDプロキシを使用します。 PGD 6では、 PGDプロキシはConnection Managerに置き換えられました。 PGD 5からPGD 6にアップグレードする場合、次の手順を使用してConnection Managerに移動します。 PGD 5- PGDプロキシから接続マネージャーへの移動を参照してください。

書き込みリーダーノードの検証#

アップグレードするノードが書き込みリーダーノードではないことを確認します。

pgd-a1:/home/rocky $ pgd group group-a show --summary

出力

Group Property    Value
- ---------------- -------
Group Name        group-a
Parent Group Name dc-1
Group Type        data
Write Leader      pgd-a2
Commit Scope

現在の書き込みリーダーはノードpgd-a2であるため、ノードpgd-a1をアップグレードするのが適切です。

アップグレードするノードの場合、書き込みリーダーを別のノードに切り替えます。

必要に応じて、 pgd group set-leader コマンドを使用して書き込みリーダーを切り替えます。

witness-a1:/home/rocky $ /usr/edb/as17/bin/pgd group group-a set-leader pgd-a1

witness-a1:/home/rocky $ /usr/edb/as17/bin/pgd group group-a show --summary

出力

 Group Property    | Value
- ------------------+---------
 Group Name        | group-a
 Parent Group Name | dc-1
 Group Type        | data
 Write Leader      | pgd-a1
 Commit Scope      |

ノードをフェンスする#

書き込みリーダーにならないように、pgd node <node-name> set-option route_fence true を使用してこのクラスター内のノードをフェンスします。

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

initdbユーティリティを実行して、新しいサーバーを初期化します。 --data-checksums オプションが設定されていることを確認します。

/usr/edb/as17/bin/initdb -D /var/lib/edb/as17/data -E UTF8 --data-checksums

デフォルトのデータディレクトリを使用したくない場合は、新しいデータディレクトリを作成します。この例では、簡単にするためにデフォルトを使用します。

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

次のファイルとディレクトリ存在する場合は、PostgreSQLのアップグレードバージョン用に作成した新しいデータディレクトリにコピーします。

postgresql.conf
postgresql.auto.conf
pg_hba.conf
conf.d ディレクトリ

cp /opt/postgres/data/postgresql.conf /var/lib/edb/as17/data/
cp /opt/postgres/data/postgresql.auto.conf /var/lib/edb/as17/data/
cp /opt/postgres/data/pg_hba.conf /var/lib/edb/as17/data/

TPA展開されたクラスターがある場合は、 conf.d ディレクトリもコピーします。

cp -r /opt/postgres/data/conf.d /var/lib/edb/as17/data/

たとえば、 operator_precedence_warning GUCが発生する場合がありますが、新しい構成では無視できます。

sudo systemctl stop postgres
sudo systemctl status postgres

PostgreSQLインスタンスがサービスとして構成されているため、この例では .. Note::: systemctlコマンドが使用されています。セットアップが異なる場合は、 pg_ctl ユーティリティの使用が必要になる場合があります。

実際のアップグレードを実行する前に、ドライランを実行して、互換性とアップグレードの実現可能性を確認します。 pgd node upgrade ツールには、アップグレードプロセスの一部のドライランを実行する--check オプションがあります。このオプションを使用して、アップグレードをスムーズに行うことができます。 --check オプションを指定してupgradeコマンドを実行します。

/usr/edb/as17/bin/pgd node pgd-a1 upgrade \
- -database bdrdb -B /usr/edb/as17/bin \
- -socketdir /tmp \
- -old-bindir /usr/edb/as13/bin \
- -old-datadir /opt/postgres/data \
- -new-datadir /var/lib/edb/as17/data \
- -username enterprisedb \
- -old-port 5444 \
- -new-port 5444 \
- -check

チェックが成功すると、次のような出力が返されます。

Performing BDR Postgres Checks
- -----------------------------
Getting old PG instance shared directory                      ok
Getting new PG instance shared directory                      ok
Collecting pre-upgrade new PG instance control data           ok
Checking new cluster state is shutdown                        ok
Checking BDR extension versions                               ok
Checking Postgres versions                                    ok

Finished BDR pre-upgrade steps, 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 contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for user-defined encoding conversions                ok
Checking for user-defined postfix operators                   ok
Checking for incompatible polymorphic functions               ok
Checking for not-null constraint inconsistencies              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*

アップグレードを実行します。#

ドライランチェックに合格した場合、 --check オプションを指定せずにコマンドを実行して、アップグレードを実行できます。

/usr/edb/as17/bin/pgd node pgd-a1 upgrade \
- -database bdrdb -B /usr/edb/as17/bin \
- -socketdir /tmp \
- -old-bindir /usr/edb/as13/bin \
- -old-datadir /opt/postgres/data \
- -new-datadir /var/lib/edb/as17/data \
- -username enterprisedb \
- -old-port 5444 \
- -new-port 5444

アップグレードが成功すると、次のような出力が返されます。

Performing BDR Postgres Checks
- -----------------------------
Getting old PG instance shared directory                      ok
Getting new PG instance shared directory                      ok
Collecting pre-upgrade new PG instance control data           ok
Checking new cluster state is shutdown                        ok
Checking BDR extension versions                               ok
Checking Postgres versions                                    ok

Collecting Pre-Upgrade BDR Information
- -------------------------------------
Collecting pre-upgrade old PG instance control data           ok
Connecting to the old PG instance                             ok
Checking for BDR extension                                    ok
Checking BDR node name                                        ok
Terminating connections to database                           ok
Waiting for all slots to be flushed                           ok
Disconnecting from old cluster PG instance                    ok
Stopping old PG instance                                      ok
Starting old PG instance with BDR disabled                    ok
Connecting to the old PG instance                             ok
Collecting replication origins                                ok
Collecting replication slots                                  ok
Disconnecting from old cluster PG instance                    ok
Stopping old PG instance                                      ok

Finished BDR pre-upgrade steps, 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 contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for user-defined encoding conversions                ok
Checking for user-defined postfix operators                   ok
Checking for incompatible polymorphic functions               ok
Checking for not-null constraint inconsistencies              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
- -----------------
Setting locale and encoding for new cluster                   ok
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/edb/as17/bin/vacuumdb -U enterprisedb --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 post-upgrade old PG instance control data          ok
Collecting post-upgrade new PG instance control data          ok
Checking LSN of the new PG instance                           ok
Starting new PG instance with BDR disabled                    ok
Connecting to the new PG instance                             ok
Creating replication origin bdr_bdrdb_dc_1_pgd_a2             ok
Advancing replication origin bdr_bdrdb_dc_1_pgd_a2 to 0/3...  ok
Creating replication origin bdr_bdrdb_dc_1_witness_a1         ok
Advancing replication origin bdr_bdrdb_dc_1_witness_a1 to...  ok
Creating replication slot bdr_bdrdb_dc_1                      ok
Creating replication slot bdr_bdrdb_dc_1_witness_a1           ok
Creating replication slot bdr_bdrdb_dc_1_pgd_a2               ok
Stopping new PG instance                                      ok

注釈

ハードリンクに`--link` オプションを使用できます。このオプションは、両方のデータディレクトリが同じファイルシステム上にある場合に機能します。詳細については、PostgreSQLドキュメントの pg_upgrade を参照してください。

アップグレード後の手順#

Postgresサービスファイルの更新#

/etc/systemd/system/postgres.service にあるPostgreSQLサービスファイルで、新しいサーバーのサーバーバージョン、データディレクトリ、およびバイナリディレクトリを更新します。

更新されたサービスファイルの例

[Unit]
Description=Postgres 17 (TPA)
After=syslog.target
After=network.target

[Service]
Type=simple
User=enterprisedb
Group=enterprisedb
OOMScoreAdjust=-1000
Environment=PG_OOM_ADJUST_VALUE=0
Environment=PGDATA=/var/lib/edb/as17/data
StandardOutput=syslog
ExecStart=/usr/edb/as17/bin/edb-postgres -D ${PGDATA} -c config_file=/var/lib/edb/as17/data/postgresql.conf
ExecStartPost=+/bin/bash -c echo 0xff > /proc/$MAINPID/coredump_filter
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
Restart=no
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

postgresサービスを開始する#

daemon-reloadを実行し、Postgresサービスを開始します。

systemctl daemon-reload
systemctl start postgres

注釈

サーバーがサービスとして実行されていない場合は、サービスファイルの更新をスキップし、 pg_ctlユーティリティを使用してサーバーを起動できます。

アップグレードされたクラスターバージョンの確認#

次のコマンドを使用して、アップグレードされたクラスターバージョンを確認します。

pgd-a1:/home/rocky $ /usr/edb/as17/bin/pgd nodes list --versions

出力

 Node Name  | BDR Version         | Postgres Version
- -----------+---------------------+------------------
 pgd-a1     | PGD Version 6.4.0 | 17.6.0
 pgd-a2     | 5.9.0               | 13.22.28
 witness-a1 | 5.9.0               | 13.22.28

ノード pgd-a1 のBDRバージョンはバージョン6.4.0にアップグレードされ、Postgresバージョンは17.6.0にアップグレードされました。

ノードのフェンスを解除する#

pgd node <node-name> set-option route_fence false を使用してこのクラスター内のノードのフェンスを解除して、書き込みリーダーにならないようにします。

接続マネージャーが動作していることを確認する#

アップグレードしたノードで接続マネージャーポートデフォルトでは6444を介してクエリーを実行します。

pgd-a1:/home/rocky $ psql "host=pgd-a1 port=6444 dbname=bdrdb user=enterprisedb " -c "select node_name from bdr.local_node_summary;"

出力

 node_name
- ----------
 pgd-a2
(1 row)

クリーンアップとバキューム分析#

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

Upgrade Complete
- ---------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
    /usr/edb/as17/bin/vacuumdb -U enterprisedb --all --analyze-in-stages
Running this script will delete the old clusters data files:
    ./delete_old_cluster.sh

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

/usr/edb/as17/bin/vacuumdb -U enterprisedb --all --analyze-in-stages

このノードを元に戻す必要がない場合は、古いクラスターのデータファイルをクリーンアップすることもできます。

./delete_old_cluster.sh

残りのノードをアップグレードする#

クラスター内のすべてのノードに対してこれらの手順を実行する必要があります。唯一の違いは、upgradeコマンドのノード名です。簡単なリファレンスのために、ノード pgd-a2 および witness-a1 のコマンドが提供されています。

ノード pgd-a2

/usr/edb/as17/bin/pgd node pgd-a2 upgrade \
- -database bdrdb -B /usr/edb/as17/bin \
- -socketdir /tmp \
- -old-bindir /usr/edb/as13/bin \
- -old-datadir /opt/postgres/data \
- -new-datadir /var/lib/edb/as17/data \
- -username enterprisedb \
- -old-port 5444 \
- -new-port 5444

ノード witness-a1

/usr/edb/as17/bin/pgd node witness-a1 upgrade \
- -database bdrdb -B /usr/edb/as17/bin \
- -socketdir /tmp \
- -old-bindir /usr/edb/as13/bin \
- -old-datadir /opt/postgres/data \
- -new-datadir /var/lib/edb/as17/data \
- -username enterprisedb \
- -old-port 5444 \
- -new-port 5444

クラスターの最終的な状態を確認する#

次のコマンドを使用して、ノードバージョンを確認します。

pgd-a2:/home/rocky $ /usr/edb/as17/bin/pgd nodes list --versions

出力

 Node Name  | BDR Version          | Postgres Version
- -----------+----------------------+------------------
 pgd-a1     | PGD Version 6.4.0  | 17.6.0
 pgd-a2     | PGD Version 6.4.0  | 17.6.0
 witness-a1 | PGD Version 6.4.0  | 17.6.0

クラスターのすべてのノードは、PGDバージョン6.4.0およびEPAS 17.6.0にアップグレードされました。

接続マネージャーの検証#

すべてのデータノードについて、次のコマンドを使用して接続マネージャーを確認します。

pgd-a2:/home/rocky $ psql "host=pgd-a2 port=6444 dbname=bdrdb user=enterprisedb " -c "select node_name from bdr.local_node_summary;"

出力

 node_name
- ----------
 pgd-a1
(1 row)

pgd-a2:/home/rocky $ psql "host=pgd-a2 port=6445 dbname=bdrdb user=enterprisedb " -c "select node_name from bdr.local_node_summary;"

出力

 node_name
- ----------
 pgd-a2
(1 row)

注釈

これで、3ノードPGD 5、EPAS 13クラスターからPGD 6、EPAS 17クラスターへのインプレースメジャーバージョンローリングアップグレードPGD & Postgresの作業例が完了しました。

Performing a Postgres major version rolling upgrade on a PGD cluster

目次

Performing a Postgres major version rolling upgrade on a PGD cluster#

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

アップグレードの準備#

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

実際の例 PGD 4からPGD 6へのアップグレード#

概要#

harp-プロキシリーダーの確認#

ノードをフェンスする#

Postgresサービスを停止します#

HARPマネージャーを停止します#

パッケージの削除とインストール#

Postgresサービスを開始する#

HARPマネージャーをスタートする#

ノードのフェンスを解除する#

すべてのノードに対して手順を繰り返します。#

クラスターバージョンの確認#

SCRAMハッシュの確認#

ルーティングを有効にする#

接続マネージャーに切り替える#

harpマネージャーとプロキシサービスを停止します。#

実際の例 PGD 5からPGD 6へのアップグレード#

前提条件#

新しいサーバーとPGDのパッケージをインストールします#

アップグレード前の手順#

バージョンチェック#

接続マネージャーに移動#

書き込みリーダーノードの検証#

ノードをフェンスする#

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

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

アップグレードを実行します。#

アップグレード後の手順#

Postgresサービスファイルの更新#

postgresサービスを開始する#

アップグレードされたクラスターバージョンの確認#

ノードのフェンスを解除する#

接続マネージャーが動作していることを確認する#

クリーンアップとバキューム分析#

残りのノードをアップグレードする#

クラスターの最終的な状態を確認する#

接続マネージャーの検証#