Upgrading your cluster#

tpaexec upgrade コマンドは、TPAクラスターで実行されているソフトウェアをアップグレードするために使用されます。 tpaexec deploy はアップグレードを実行しません。

このコマンドは、以前のtpaexec update-postgres コマンドを置き換えます。

注釈

TPAは、共有Barmanおよび/または共有PEM構成を持つクラスターでの`tpaexec upgrade` コマンドの使用をまだサポートしておらず、将来のリリースでこの機能を追加します。

config.ymlに変更を加えた場合、それらの変更を適用する方法は、tpaexec provision に続いてtpaexec deploy を実行することです。

このルールの例外は、 tpaexec deploy が既にインストールされているパッケージの別のバージョンのインストールを拒否することです。代わりに、tpaexec upgrade を使用してソフトウェアアップグレードを実行する必要があります。

次のコンポーネントは、 任意の アーキテクチャでアップグレードできます。

Postgres
Repmgrリダイレクトpgbouncer
共有Barmanまたは共有PEMクラスター
PG Backup API
共有Barmanまたは共有PEMクラスター

サーバーとエージェントの両方

次のコンポーネントは M1 アーキテクチャでアップグレードでき、使用されるフェールオーバーマネージャーに応じて異なります。

次のコンポーネントは、使用するBDRバージョンに応じて、 BDR -Always-ON / PGD-Always-ON アーキテクチャでアップグレードできます。

pgdcli BDR 4の場合はv1、PGD5の場合はv5
pgd-proxy-config PGD5のみ

M1アーキテクチャと、M1に該当するすべてのフェールオーバーマネージャー、upgrade は、 Postgres 、対応するフェールオーバーマネージャーEFM 、Patroni またはrepmgr 、および選択された非アーキテクチャ固有のコンポーネントのマイナーバージョンのアップグレードを実行できます。
PGDアーキテクチャでは、 upgrade は、 PostgresとBDR拡張機能、および明示的にオプトインされている場合 pgd-cli およびpgd-proxy のマイナーバージョンのアップグレードを実行します。
PGDアーキテクチャでは、 reconfigure コマンドとの組み合わせでのみ、 upgrade はBDR拡張機能のメジャーバージョンのアップグレードを実行できます。

他のクラスターコンポーネントのアップグレードのサポートがTPA v23.41.0 に追加されました _特定のコンポーネント EFM などは例外です。詳細については、各コンポーネントのドキュメントのupgrade セクションを参照してください。

アップグレードするときは、アップグレードを開始する前に常にbarmanを使用してバックアップをとり、アップグレードのために確保されている時間中に実行されるスケジュールされたバックアップを無効にする必要があります。

一般に、TPAはインスタンスごとに続行し、影響を受けるサービスの停止、新しいパッケージのインストール、必要に応じて構成の更新、サービスを再起動し、ランタイム構成の変更を実行してから、次のインスタンスで同じことを行う前に。プロセス中の任意の時点で、クラスターのノードの1つだけが使用不可になります。

クラスターをPGD-Always-ONにアップグレードする場合、既存のPGD-Always-ONクラスターをアップグレードする場合、またはPGD-SまたはPGD-Xクラスターのマイナーアップグレードを実行する場合、オプション-e enable_proxy_monitoring=true をtpaexec upgrade コマンドラインに追加して、アップグレードします。有効にすると、bdrデータベースに追加のテーブルが作成され、アップグレードの実行中に監視データがそこに書き込まれます。モニタリングを有効にすることによるパフォーマンスへの影響は非常に小さいため、有効にすることをお勧めします。

アップグレードする前に#

このセクションでは、tpaexec upgrade を実行する前にクラスターで実行する必要があるチェックについて説明します。これらを順番に行うと、ライブクラスターに影響を与える前に、最も一般的な問題をキャッチします。

クラスターの状態を確認する#

アップグレードは、正常な状態にあるクラスターで実行するのが最も簡単です。 tpaexec test <cluster> を実行して、標準のヘルスチェックを実行します。アップグレードプロセス自分自身はアップグレード前のヘルスチェックを実行しますが、事前に問題を検出すると、それに対処する時間が長くなります。

BDR対応アーキテクチャの場合、すべてのノードがカタログに表示されることも確認します。

SELECT node_name, peer_state_name, peer_target_state_name
  FROM bdr.node_summary;

すべてのエントリはACTIVE または読み取り専用スタンバイの場合はSTANDBY を報告する必要があります。続行する前に、他の状態を調査します。

repmgrを使用するM1クラスターの場合、プライマリでrepmgr cluster show を実行し、すべてのノードが実行中および接続されていると表示されることを確認します。

バックアップの検証#

アップグレードの前に、最近のBarmanバックアップが存在し、復元可能な状態にあることを確認してください。 Barmanホストの場合

sudo -u barman barman list-backup <server>
sudo -u barman barman check <server>

ここで失敗したステータスは、開始する前に調査する必要があります。アップグレードが進行すると、 Barman WALレシーバーが停止されるため、アップグレードウィンドウ中のバックアップランドスケープは、事前に存在したものに固定されます。

レプリケーションラグの検証#

クラスターは高レベルで正常な場合がありますが、個々のレプリカは遅延している場合があります。アップグレードは、各インスタンスを順番にフェンスします。レプリカが大幅に遅れている場合、フェンスを解除した後に追いつくのに時間がかかり、全体のアップグレード時間が長くなります。

PGDクラスターの場合

SELECT slot_name, active, restart_lsn, write_lag, flush_lag, replay_lag
  FROM bdr.node_slots;

M1クラスターの場合、プライマリで

SELECT application_name, state, write_lag, flush_lag, replay_lag
  FROM pg_stat_replication;

分ではなく秒単位で測定される遅延を目指します。開始する前に、大幅に遅れているレプリカを調査します。

パッケージバージョンのピンとレビュー#

アップグレード中にインストールされるものを制御するには、 tpaexec upgrade を実行する前にconfig.yml でパッケージバージョンを明示的に設定することをお勧めします。関連する変数は、postgres_package_version 、bdr_package_version 、pgd_proxy_package_version 、pgdcli_package_version 、およびコンポーネント固有の同等品です。

明示的なピンがないと、TPAは各コンポーネントの利用可能な最新のパッケージをインストールします。これにより、意図しないメジャーバージョンのアップグレードが発生する可能性があります。パッケージバージョンの選択を参照

詳細については。

注釈

config.yml のバージョンを更新した後、 tpaexec provision を実行してインベントリを再生成します。

アップグレードするすべてのコンポーネントのターゲットバージョンのリリースノートを確認しますが、現在のバージョンとターゲットバージョン間のリリースノートも確認します。 EDBのPGDおよびPostgresリリースノートでは、バージョン固有のアップグレードの考慮事項、つまりアップグレードの前後に変更する必要がある設定、非推奨、および動作の変更を呼びかけている場合があります。同じことは、アップグレードの実行に使用しているTPAの新しいバージョンのTPA独自のリリースノートにも適用されます。

ステージング環境でアップグレードをテストする#

tpaexec upgrade は、クラスターをインスタンスごとに処理します。アップグレードはローリング中です。一度に1つのインスタンスのみがフェンスオフされます。ただし、合計ウォールクロック時間は、クラスターサイズ、アップグレードするコンポーネントの数、各インスタンスのストレージとネットワークの特性だけでなく、アップグレードシナリオが問題なく完了するかどうかにも依存します。

実稼働クラスターのアーキテクチャ、Postgresのフレーバーとバージョン、パッケージのピン留め、およびカスタムフックと一致する非実稼働環境でアップグレードを再現することを強くお勧めします。これにより、ライブトラフィックに影響を与える前に、予期せぬ事態構成済みリポジトリ内のパッケージの欠落、予期しない構成のドリフトをキャッチします。

スケジュールされたジョブを無効にする#

アップグレードウィンドウ中にクラスターに対して実行されるようにスケジュールされているものはすべて一時停止する必要があります。代表的な商品

データベースにヒットするCronジョブアナリティクス、レポート。
アップグレードを認識しない外部バックアップツール。
長時間実行される移行またはバッチジョブ。

TPA自分自身は、開始する前にBarman WALレシーバーを停止し、その後再起動します。 Barmanを手動で無効にする必要はありません。

アップグレード中#

このセクションでは、tpaexec upgrade の実行中に予想されることと、TPAの外部から注意すべきことについて説明します。

予想されること#

TPAは、クラスターを一度に1インスタンスずつ処理します。インスタンスごとに、アップグレードは次のとおりです。

インスタンスをフェンスオフして、プロキシまたはフェールオーバーマネージャーが新しい接続の送信を停止します。
そのインスタンスで影響を受けるサービスを停止します。
新しいパッケージをインストールします。
必要に応じて構成ファイルを更新します。
サービスを再起動し、起動するまで待機します。
インスタンスのフェンスを解除します。

各インスタンスがフェンスされている間、およびサービスに戻ったときに、短い接続の中断が発生することを想定してください。接続プーリングと再試行ロジックを使用するアプリケーションは、通常、これらの移行中にクライアントに表示されるエラーを認識しないはずです。

非リーダーノードの各ノードがアップグレードされている間、書き込みトラフィックは、現在の書き込みリーダーを介して継続されます。書き込みリーダー自分自身がアップグレードされるたびに、短いリーダー選択の中断が発生します。 PGD-SおよびPGD-Xは、書き込みリーダーが最後にアップグレードされるように手配します。 PGD-Always-ONはインベントリの順序でノードをアップグレードするため、現在のリーダーの番が巡って来るたびにリーダー選挙が発生します。

アプリケーション側で見るべきもの#

アップグレードの実行中、各フェンス/アンフェンスの移行で短い一時停止が発生するのは通常です。複数のインスタンスにわたる持続的な接続障害はそうではありません。これらが表示された場合は、TPAが次のインスタンスに進む前に停止して調査します。

アップグレード中にクラスターに対してアプリケーションが実行されている場合、以下を監視します。

アプリケーションエラー率一時的な再試行が予想されます。持続的なエラーはそうではありません。
接続プールメトリック使用可能な接続の一時的な低下が予想されます。
レプリケーションスロットの遅延各インスタンスがアップグレード後に追いつくと、一時的に増加する場合があります。

アップグレード後#

このセクションでは、tpaexec upgrade が完了したら実行する必要がある検証について説明します。

インストールされたパッケージバージョンの確認#

新しいパッケージがすべてのインスタンスにインストールされることを確認します。 RHELファミリーホストの場合

tpaexec cmd <cluster> all -m shell -a rpm -qa | grep -E "^(postgres|edb-)"

Debian / Ubuntuホストの場合

tpaexec cmd <cluster> all -m shell -a dpkg -l | grep -E "(postgres|edb-)"

同じパッケージバージョンは、同じロールのすべてのインスタンスで報告される必要があります。

サービスとレプリケーションの検証#

すべてのサービスが正常に再起動したことを確認します。

tpaexec cmd <cluster> all -m shell -a systemctl is-active postgres

PGDクラスターの場合、 BDRが完全に再コンバートしたことを確認します。

SELECT node_name, peer_state_name FROM bdr.node_summary;

repmgrを使用したM1クラスターの場合

tpaexec cmd <cluster> role_primary -m shell -a repmgr -f /etc/repmgr.conf cluster show

新しいバックアップを取ります#

重要なアップグレードの後、クラスターの新しいBarmanバックアップを取得します。

tpaexec cmd <cluster> role_barman -m shell -a sudo -u barman barman backup <server>

これにより、アップグレード後の状態を反映する既知の正常な復元ポイントが得られます。

スケジュールされたジョブを再度有効にする#

アップグレードの前にcronジョブ、バッチジョブ、または外部スケジュールされたタスクを無効にした場合、ここでそれらを再度有効にします。 TPA独自のBarman WALレシーバーは、自動的に再起動されます。

tpaexecテストを実行する#

最終的なスモークチェックとして、標準のテストスイートを実行します。

tpaexec test <cluster>

これにより、接続、レプリケーション、ロールマッピング、およびアップグレード前に実行されたコンポーネント固有のチェックが実行されます。クリーンテストの実行は、アップグレードが完了したことの最も簡単なエンドツーエンドの確認です。

失敗したアップグレードからの復旧#

tpaexec upgrade が障害を報告した場合、クラスターは、障害が発生したときに処理されていたインスタンスで既知の状態のままです。後続のインスタンスはタッチされません。

ロールバックする場合、EDBサポートに電話する場合#

ロールバックは、TPAが不可逆的なカタログ変更を適用する前にのみ安全です。通常は、メジャーバージョンのアップグレードで発生するBDR側の構成の更新です。これらの変更が適用されると、正しいパスは逆方向ではなく前方になります。

続行するかロールバックするかがわからない場合は、停止してEDBサポートに連絡してください。

失敗した実行のansible.log 。
tpaexec test <cluster> の出力。
どのインスタンスがアップグレードを完了し、どのインスタンスが完了していないかの説明。
使用されるconfig.yml。
オプションでEDB lassoレポートまたはその他の意味のあるログ。

よくある落とし穴#

このセクションには、過去にユーザーを魅了したいくつかの特定の状況が統合されています。

固定されたパッケージバージョンによりno-opアップグレードが発生する#

postgres_package_version または他のxxx_package_version がインストールされたパッケージと既に一致する場合、 tpaexec upgrade はコンポーネントを「既に目的のバージョン」として報告し、何も行いません。この症状は、実行が変更なしですぐに完了し、目的のバージョンがインストールされていないことです。

修正 config.yml を更新して目的の新しいバージョンを設定し、 tpaexec provision 、続いてtpaexec upgrade を再実行します。詳細は、パッケージバージョンの選択を参照してください。

共有Barmanまたは共有PEMクラスター#

TPAは、現在、共有Barmanまたは共有PEM構成を使用するクラスターに対するtpaexec upgrade の実行をサポートしていません。この制限は、早期に中止されるアップグレードの前提条件によって適用されます。サポートが追加されるまで、これらのクラスターシェイプのアップグレードはTPAの外部で手動で実行する必要があります。 After a manualmajor-version Postgres upgrade を参照してください

その後にクラスターを調整する方法については。

コンポーネントの選択#

注釈

コンポーネントのアップグレードは厳密にオプトインです

tpaexec upgrade ~/clusters/speedy

更新する特定のコンポーネントを選択するために、--components フラグはコンマ区切りリストを取ります

tpaexec upgrade ~/clusters/speedy \
   --components=postgres,pgd-proxy,pgdcli,pgbouncer,pg-backup-api,barman

クラスター内の該当するすべてのコンポーネントを更新する必要がある場合は、all をフラグに渡すことができます

tpaexec upgrade --components=all

component	value	architecture
Barman	barman	all
PEM	pem-server,pem-agent	all
PgBackupAPI	pg-backup-api	all
PgBouncer	pgbouncer	all
EFM	efm	M1 with failover_manager=efm
etcd	etcd	M1 with failover_manager=patroni
Patroni	patroni	M1 with failover_manager=patroni
RepMgr	repmgr	M1 with failover_manager=repmgr
PGD Cli	pgdcli	BDR-Always-ON, PGD-Always-ON
PGD-Proxy	pgd-proxy	PGD-Always-ON
Postgres,EPAS,PGE	postgres	All
All	all	All

パッケージバージョンの選択#

デフォルトでは、クラスターを作成したときにパッケージバージョンPostgres、PGD、またはpglogicalなどを明示的に指定しなかった場合、tpaexec upgrade はインストールされたパッケージの最新の利用可能なバージョンに更新します。

この場合、config.ymlを編集し、バージョン設定を更新し、tpaexec provision を再実行する必要があります。更新により、選択したバージョンのパッケージがインストールされます。以下に示すように、コマンドラインでバージョンを指定することにより、特定のバージョンに更新することもできます。

tpaexec upgrade ~/clusters/speedy -vv      \
  --components=postgres,pgbouncer          \
  -e postgres_package_version="16.10*"     \
  -e pgbouncer_package_version="1.24*"     \
  -e bdr_package_version="5.9.0*"

ここでのバージョン構文は、OSディストリビューションとパッケージマネージャーによって異なることに注意してください。特に、yumは*xyz* ワイルドカードを受け入れますが、aptはxyz* のみを理解します上記の例のように。

PGDクラスターの場合、パッケージマネージャーの依存関係の解決に依存して正しい依存関係を選択するのではなく、3つのコンポーネントすべてPostgres、PGD、pglogical の正確なバージョンを明示的に指定することをお勧めします。

運用環境で実行する前に、QA環境でアップグレードをテストすることを強くお勧めします。

構成#

特定の場合、マイナーバージョンのアップグレードではconfig.ymlを変更する必要はありません。 config.yml でpostgres_package_version が定義されていない場合、 tpaexec upgrade が実行されると、Postgresを使用可能な最新のマイナーバージョンに正常にアップグレードします。それが正確に何を意味するかは、クラスターの詳細によって異なります。

他のコンポーネントのマイナーバージョンのアップグレードを制御するには、 tpaexec upgrade を実行する前にconfig.yml で特定のxxx_package_version が指定されていることを確認し、 --components=x,y,z フラグまたは--components=all を使用して特定のコンポーネントをアップグレードするように明示的にオプトインすることをお勧めします。クラスター）。 config.yml でxxx_package_version を固定せずにtpaexec upgrade を実行し、一部またはすべてのコンポーネントをアップグレードすることをオプトインすると、インストールされたコンポーネントパッケージのメジャーバージョンのアップグレードが発生する可能性があります。互換性が損なわれる可能性があるため、TPAはサポートしていません。

場合によっては、アップグレードには、新しいパッケージのインストールとサービスの再起動を超える追加の手順が含まれる場合があります。たとえば、 BDR4からPGD5にアップグレードするには、新しいパッケージリポジトリをセットアップし、プロセス中にBDRノードとグループ構成に特定の変更を加える必要があります。

このような場合、ソフトウェアのアップグレードを有効にするプロセスの一部として必要な複雑な手順がある場合、 tpaexec upgrade はこれらの手順を実行します。たとえば、上記のシナリオでは、新しいPGD5パッケージリポジトリを構成します通常、これはdeployでも行います。

ただし、アップグレードプロセス自分自身に直接必要な変更のみを行います。たとえば、config.ymlを編集して新しいPostgresユーザーまたはデータベースを追加する場合、これらの変更はアップグレード中に行われません。混乱を避けるために、ソフトウェアのアップグレードプロセスを開始する前に、無関係の保留中の変更をtpaexec deploy することをお勧めします。

BDR-Always-ONからPGD-Always-ONへのアップグレード#

BDR-Always-ONからPGD-Always-ONつまりBDR3/4からPGD5にアップグレードするには、最初にtpaexec reconfigure を実行します。

tpaexec reconfigure ~/clusters/speedy\
  --architecture PGD-Always-ON\
  --pgd-proxy-routing local

このコマンドは、config.ymlを読み取り、クラスターをアップグレードするために必要な変更を行い、新しいconfig.ymlを書き込みます。呼び出しの詳細については、 tpaexec reconfigure を参照してください。変更を確認した後、tpaexec upgrade を実行してアップグレードを実行します。

tpaexec upgrade ~/clusters/speedy\

または、プロキシモニタリングを有効にしてアップグレードを実行するには、

tpaexec upgrade ~/clusters/speedy\
  -e enable_proxy_monitoring=true

tpaexec upgrade はtpaexec provision を自動的に実行して、Ansibleインベントリーを更新します。アップグレードプロセスでは、次のことを行います。

クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。
クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。
クラスター内のBDRノードごとに、一度に1つずつ
- harp-プロキシがそれに接続を送信しないことを保証にノードをフェンスオフします。
- BDR4をPGD5に置き換えるなど、postgresを停止、更新、および再起動します。
- ノードのフェンスを解除して、接続を再度受信できるようにします。
- このノードに適用されるpgbouncerおよびpgd-cliを更新します。
クラスター内のインスタンスごとに、 BDR v5専用のBDR構成を更新します
クラスター内のプロキシノードごとに、一度に1つずつ
- pgd-proxy.
- をセットアップします harp-proxy.
- を停止します pgd-proxyを起動します。
harp-proxyとそのサポートファイルを削除します。

PGD-Always-ONからPGD-Xへのアップグレード#

PGD-Always-ON クラスターのPGD-X へのアップグレードは、 重要なアーキテクチャの進化 であり、単純な ソフトウェアの更新 を超えた変更を含みます。これは、_注意深く調整された多段階プロセス_であり、最終的なソフトウェアのアップグレードを実行する前に、個別のフェーズでクラスターを再構成する必要があります。このプロシージャーは、最初にpgd-proxy をビルトインConnection Manager に置き換えることにより、PGD 5 クラスターの接続処理を最新化します。このステップは、現在ライブクラスターでの手動操作を必要としますが、将来のTPAリリースで自動化が計画されています。次に、クラスターを新しいPGD-X に移行します。アーキテクチャ。

アップグレードプロセスは、クラスターを3つの異なる状態を介して移行します。

開始 PGD 5.9+ (PGD-Always-ON ) PGD-Proxy を使用
中級 PGD 5.9+ (PGD-Always-ON )ビルトインConnection Manager を使用するようになりました
最終 PGD 6 (PGD-X Architecture )

前提条件#

開始する前に、次の要件を満たしていることを確認してください。

クラスターバージョン クラスターはPGD バージョン5.9以降を実行している必要があります。以前の5.xバージョンを使用している場合は、tpaexec upgrade を使用して最初に最新のマイナーバージョンにアップグレードします。 PGD-Always-ONクラスターのマイナーバージョンのアップグレードの詳細については、セクション#pgd-always-onを参照してください。
バックアップ クラスターの現在のテストされたバックアップがあります。
オーバーライドの確認 インスタンスレベルのプロキシオーバーライドたとえば pgd_proxy_options などについてconfig.yml を確認しました。これらは自動的に移行できないため、手動での介入が必要です。
共同ホストプロキシ PGD 5 クラスターは、共同ホストプロキシを使用して構成する必要がありますここで pgd-proxy ロールはbdr ロールと同じインスタンスにあります。スタンドアロンプロキシインスタンスが存在すると、switch2cm コマンドが中止されます。移行を続行する前に、クラスターからスタンドアロンプロキシインスタンスを削除する必要があります。

ステージ1ビルトイン接続マネージャーへの移行#

最初のステージは、 PGD 5.9+ クラスターを再構成して、外部pgd-proxy の使用から最新のビルトインConnection Manager に切り替えることです。 TPAは、 tpaexec switch2cm コマンドを提供して、最小限のダウンタイムでこの移行を自動化します。

次のコマンドを実行して、config.yml ファイルを更新します。これにより、ビルトインConnection Manager を有効にするために必要な設定が追加されます。

このアクションは構成ファイルのみを変更します。データベースクラスターの実行状態はまだ変更されません。

新しいバージョンを書き込む前に、reconfigure は、現在のファイルたとえば config.yml.~1~ のバックアップを自動的に保存し、安全な復元ポイントを提供します。

呼び出しの詳細については、 tpaexec reconfigure を参照してください。

tpaexec reconfigure ~/clusters/speedy --enable-connection-manager

ステップ1.2接続マネージャーに切り替える#

tpaexec switch2cm コマンドを実行して、pgd-proxy からビルトインConnection Manager への移行を実行します。このコマンドは、 tpaexec provision を自動的に実行してAnsibleインベントリーを更新し、最小限のダウンタイムですべてのノードをスイッチします。

tpaexec switch2cm ~/clusters/speedy

switch2cm コマンドは、次の操作を実行します。

接続マネージャー設定でAnsibleインベントリーを更新します
各ノードごと
- ノードをフェンスして新しい接続を防止します
- PostgreSQLを再起動して接続マネージャー構成をロードします
- pgd-proxy サービスを停止します
- PostgreSQLを再度起動して接続マネージャーがポートをバインドできるようにしますb_tran_7 接続マネージャーがリッスンを開始するのを待機します
- ノードのフェンスを解除し、接続を確認します

このプロセスは、公式 EDB Connection Manager Migrationprocedure に従います。

ステージ1完了#

このステージの最後に、ビルトインConnection Manager で実行されるPGD クラスターが作成されます。これは中間状態であり、ステージ2に直接進む必要があります。マイナーバージョンアップグレードのtpaexec upgrade は、この中間状態では サポートされていません が、 PGD 6へのアップグレードが完了するまでtpaexec deploy を実行することをお勧めします。

ステージ2アーキテクチャのPGD-Xへのアップグレード#

クラスターがConnection Manager で実行されたら、最後の構成手順に進んで、PGD 6 アップグレードの準備をできます。

注釈

Stage 1 が正常に完了し、ビルトイン`Connection Manager` で実行されているクラスターからこのプロセスを開始する必要があります。

次のコマンドを実行して、新しいアーキテクチャに合わせてconfig.yml を更新します。これにより、クラスターアーキテクチャタイプが変更され、BDR バージョンが6に設定され、古い古い設定が削除されます。

このアクションは構成ファイルのみを変更します。データベースクラスターの実行状態はまだ変更されません。

tpaexec reconfigure ~/clusters/speedy --architecture PGD-X

ステップ2.2ソフトウェアのアップグレードを実行する#

config.yml の最終的な変更を確認した後、標準のtpaexec upgrade コマンドを実行できます。これにより、すべてのノードでソフトウェアのアップグレードが実行され、クラスターがPGD 6 になります。

tpaexec upgrade ~/clusters/speedy

または、プロキシモニタリングを有効にしてアップグレードを実行するには、

tpaexec upgrade ~/clusters/speedy\
  -e enable_proxy_monitoring=true

tpaexec upgrade はtpaexec provision を自動的に実行して、Ansibleインベントリーを更新します。アップグレードプロセスでは、次のことを行います。

クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。
クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。
クラスター内のBDRノードごとに、一度に1つずつ
- ノードをフェンスオフして、接続がないようにします。
- PGD5をPGD6に置き換えるなど、postgresを停止、更新、および再起動します。
- ノードのフェンスを解除して、
- このノードに適用されるpgbouncerおよびpgd-cliを更新します。
BDR v6専用のBDR構成を適用します

アップグレードの完了#

クラスターはPGD-X アーキテクチャでPGD 6 を実行し、通常のようにtpaexec deploy とtpaexec upgrade の両方で完全に管理可能です。

PGD-SまたはPGD-X#

既存のPGD6 PGD-SまたはPGD-Xクラスターを最新の利用可能なソフトウェアバージョンにアップグレードする場合、アップグレードプロセスは次を実行します。

クラスターが正常であること、およびノードが構成済みのポートでリッスンしていることを確認します。
アップグレードするノードにローカルリポジトリを含むリポジトリが構成および更新されていることを確認します。
更新されたパッケージをインストールできることの確認
クラスター内の各BDRノードを一度に1つずつアップグレードします。

重要: 高可用性を保証するために、書き込みリーダーがアップグレードされるノードの中にある場合、アップグレードされる最後のノードになります。

接続を受け入れないようにノードをフェンスします
postgres
postgresと更新PGDパッケージ
ノードのフェンスを解除して、接続を再度受信できるようにします
BDRクラスターが再確立されたことを確認します Raftコンセンサス使用b_tran_6 アップグレードされたノードが構成済みのポートでリッスンしていることを確認します

クラスターヘルスチェックを再実行します
アップグレードされたパッケージに関する情報を出力します

PGD-Always-ON#

既存のPGD-Always-ON PGD5クラスターを最新の利用可能なソフトウェアバージョンにアップグレードする場合、アップグレードプロセスは次を実行します。

クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。
クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します
クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。
選択したすべてのコンポーネントを目的のバージョンに更新できることを確認しますパッケージバージョンが提供されている場合
クラスター内のBDRノードごとに、一度に1つずつ
- pgd-proxyが接続を送信しないようにノードをフェンスオフします。
- postgresを停止、更新、および再起動します。
- ノードのフェンスを解除しますので、
- pgd-proxyおよびpgd-cliソフトウェアの更新明示的にオプトインした場合
クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って
必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合

BDR-Always-ON#

BDR-Always-ONクラスターの場合、アップグレードプロセスはクラスターインスタンスを1つずつ実行し、次のことを実行します。

クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。
クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します
クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。
サーバーがメンテナンス中であることをhaproxyに伝えます。
インスタンスがアクティブサーバーの場合、pgbouncerに再接続し、アクティブなセッションが閉じられるまで待機するように要求します。
Postgresを停止し、 Postgres、etcd、およびpgdcli該当する場合およびオプトインの場合パッケージを更新し、Postgresを再起動します。
最後に、haプロキシを介して要求を受信するためにサーバーを再度「準備ができている」としてマークします。
クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って
必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合

PGD論理スタンバイまたは物理レプリカインスタンスは、haproxyまたはpgbouncerの相互作用なしで更新されます。クラスター内の非Postgresインスタンスは放置されます。

M1#

M1クラスターの場合、upgrade は最初にストリーミングレプリカと監視ノードを更新し、次に tpaexec switchover

プライマリからアップグレードされたレプリカのいずれかに移行し、プライマリを更新し、最初のプライマリノードにスイッチオーバーします。

クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。
クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します
クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。
ストリーミングレプリカと監視のPostgresを更新します。ノード該当する場合
プライマリからアップグレードされたレプリカのいずれかに tpaexec switchover を実行します
プライマリでPostgresを更新する
最初のプライマリノードにスイッチオーバーします。
クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って
必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合

アップグレードプロセスの制御#

update_hosts 変数を定義することにより、クラスターのインスタンスがアップグレードされる順序を制御できます。

tpaexec upgrade ~/clusters/speedy \
  -e update_hosts=quirk,keeper,quaver

これは、シャドウサーバーが最初にアップグレードされるように、アクティブなPGDプライマリインスタンスを最後にリストすることにより、アップグレード中のリード/シャドウのスイッチオーバーを最小限に抑えるのに役立つ場合があります。

環境で追加のアクションが必要な場合、 TPA hooks

パッケージのインストール手順の前後にカスタムAnsibleタスクを実行できます。

ノードのサブセットのアップグレード#

update_hosts 変数を設定することにより、インスタンスのサブセットでローリングアップグレードを実行できます。ただし、この機能のサポートはアーキテクチャによって異なります。

M1 アーキテクチャの場合、この機能はrepmgr およびPatroni 管理対象クラスターで完全にサポートされています。 EFM 管理対象クラスターは、EFMを除くすべてのコンポーネントのupdate_hosts リストを尊重します。 EFMはデータノード全体で異なるバージョンを実行しているクラスターをサポートしていないため、update_hosts で指定されたノードに関係なく、すべてのデータノードはEFMバージョンをアップグレードします。
PGD-Always-ON/ BDR-Always-ON の場合、これはマイナーバージョンのアップグレード中にのみサポートされています。

PGD-Always-ON/ BDR-Always-ONのベストプラクティス#

PGDノードのサブセットでマイナーアップグレードを実行する場合、**RAFTリーダーノードを最後に更新することを強くお勧めします。この戦略により、クラスターがBDRの混合バージョンを実行している間のアップグレード後チェックに関する潜在的な問題を回避します。

PGD-SおよびPGD-X#

tpaexec upgrade は、現在の書き込みリーダーがPGD-SおよびPGD-Xクラスターの最後にアップグレードされるように自動的に調整します。Postgres / PGDローリングフェーズは2つのserial: 1 プレイに分割され、1つは現在の書き込みリーダーを除くすべてのBDRデータノードに、もう1つはリーダー自分自身を書き込みます。これらのアーキテクチャでリーダー-最後のシーケンスを達成するために追加の手順は必要ありません。

Upgrading your cluster

目次

Upgrading your cluster#

アップグレードする前に#

クラスターの状態を確認する#

バックアップの検証#

レプリケーションラグの検証#

パッケージバージョンのピンとレビュー#

ステージング環境でアップグレードをテストする#

スケジュールされたジョブを無効にする#

アップグレード中#

予想されること#

アプリケーション側で見るべきもの#

アップグレード後#

インストールされたパッケージバージョンの確認#

サービスとレプリケーションの検証#

新しいバックアップを取ります#

スケジュールされたジョブを再度有効にする#

tpaexecテストを実行する#

失敗したアップグレードからの復旧#

ロールバックする場合、EDBサポートに電話する場合#

よくある落とし穴#

固定されたパッケージバージョンによりno-opアップグレードが発生する#

共有Barmanまたは共有PEMクラスター#

コンポーネントの選択#

パッケージバージョンの選択#

構成#

BDR-Always-ONからPGD-Always-ONへのアップグレード#

PGD-Always-ONからPGD-Xへのアップグレード#

前提条件#

ステージ1ビルトイン接続マネージャーへの移行#

ステップ1.2接続マネージャーに切り替える#

ステージ1完了#

ステージ2アーキテクチャのPGD-Xへのアップグレード#

ステップ2.2ソフトウェアのアップグレードを実行する#

アップグレードの完了#

PGD-SまたはPGD-X#

PGD-Always-ON#

BDR-Always-ON#

M1#

アップグレードプロセスの制御#

ノードのサブセットのアップグレード#

PGD-Always-ON/ BDR-Always-ONのベストプラクティス#

PGD-SおよびPGD-X#