Upgrading your cluster

Upgrading your cluster#

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

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

はじめに#

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

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

TPAがアップグレードできるものはアーキテクチャによって異なります。

  • M1アーキテクチャと、M1に該当するすべてのフェールオーバーマネージャー、upgrade は、Postgresのマイナーバージョンのアップグレードのみを実行します。

  • PGDアーキテクチャでは、upgrade はPostgresとBDR拡張機能のマイナーバージョンのアップグレードを実行します。

  • PGDアーキテクチャでは、 reconfigure コマンドとの組み合わせでのみ、 upgrade はBDR拡張機能のメジャーバージョンのアップグレードを実行できます。

他のクラスターコンポーネントのアップグレードのサポートは、将来のリリースで計画されています。

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

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

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

構成#

多くの場合、マイナーバージョンのアップグレードでは、config.ymlを変更する必要はありません。 tpaexec upgrade を実行するだけで、インストールされたパッケージの利用可能な最新バージョンに優雅な方法でアップグレードします。それが正確に何を意味するかは、クラスターの詳細によって異なります。

場合によっては、アップグレードには、新しいパッケージのインストールとサービスの再起動を超える追加の手順が含まれる場合があります。たとえば、 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インベントリーを更新します。アップグレードプロセスでは、次のことを行います。

  1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。

  2. クラスター内のインスタンスごとに、正しいリポジトリーが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。

  3. クラスター内のBDRノードごとに、一度に1つずつ

    • harp-プロキシがそれに接続を送信しないことを保証にノードをフェンスします。

    • BDR4をPGD5に置き換えるなど、postgresを停止、更新、および再起動します。

    • ノードのフェンスを解除して、接続を再度受信できるようにします。

    • このノードに適用されるpgbouncerおよびpgd-cliを更新します。

  4. クラスター内のインスタンスごとに、 BDR v5専用のBDR構成を更新します

  5. クラスター内のプロキシノードごとに、一度に1つずつ

    • pgd-proxy.

    • をセットアップします harp-proxy.

    • を停止します pgd-proxyを起動します。

  6. harp-proxyとそのサポートファイルを削除します。

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

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

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

  1. 開始 PGD 5.9+ (PGD-Always-ON ) PGD-Proxy を使用

  2. 中級 PGD 5.9+ (PGD-Always-ON )ビルトインConnection Manager を使用するようになりました

  3. 最終 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 ロールと同じインスタンスにあります。スタンドアロンプロキシインスタンスは、このアップグレードパスでは サポートされていません 。

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

最初のステージは、 PGD 5.9+ クラスターを再構成して、外部pgd-proxy の使用から最新のビルトインConnection Manager に切り替えることです。

!!!移行状態のみに注意してください

このプロセスは、 PGD 6 にアップグレードする前の中間ステップとしてのみを目的とした移行的なPGD 5.9+ クラスター状態を作成します。 TPAは現在、この特定のConnection Manager 構成でのtpaexec upgrade の使用をサポートしていません。将来のTPAリリースは、 Connection Manager を使用したPGD 5 のライフサイクル管理を完全にサポートします。

この段階では、構成の変更を適用するために、ライブクラスターに大幅な手動介入が含まれます。これらの手順の実行に慣れていない場合は、このプロセスを完全に自動化する将来のTPAリリースを待つことをお勧めします。

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

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

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

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

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

ステップ1.2構成を適用し、接続マネージャーをアクティブにする#

構成の変更をライブクラスターに適用します。これは 手動 操作タスクであり、 Postgres構成パラメーターの追加、pgd-proxy サービス、およびPostgreSQL ノードをローリング方法で再起動してConnection Manager をアクティブにすることが含まれます。

このプロセスの詳細な手順については、公式 Connection Manager MigrationGuide に従ってください。

ステージ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インベントリーを更新します。アップグレードプロセスでは、次のことを行います。

  1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。

  2. クラスター内のインスタンスごとに、正しいリポジトリーが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。

  3. クラスター内のBDRノードごとに、一度に1つずつ

    • ノードをフェンスオフして、接続がないようにします。

    • PGD5をPGD6に置き換えるなど、postgresを停止、更新、および再起動します。

    • ノードのフェンスを解除して、

    • このノードに適用されるpgbouncerおよびpgd-cliを更新します。

  4. BDR v6専用のBDR構成を適用します

アップグレードの完了#

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

PGD-Always-ON#

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

  1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。

  2. クラスター内のインスタンスごとに、正しいリポジトリーが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。

  3. クラスター内のBDRノードごとに、一度に1つずつ

    • pgd-proxyが接続を送信しないようにノードをフェンスオフします。

    • postgresを停止、更新、および再起動します。

    • ノードのフェンスを解除しますので、

    • このノードに適用されるpgbouncer、pgd-proxy、およびpgd-cliを更新します。

BDR-Always-ON#

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

  1. サーバーがメンテナンス中であることをhaproxyに伝えます。

  2. インスタンスがアクティブサーバーの場合、pgbouncerに再接続し、アクティブなセッションが閉じられるまで待機するように要求します。

  3. Postgresを停止し、パッケージを更新し、Postgresを再起動します。

  4. 最後に、haproxyを介して要求を受信するためにサーバーを再度「準備ができている」としてマークします。

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

M1#

注釈

M1アーキテクチャは、Postgresのマイナーバージョンのアップグレードのみをサポートしています。 M1に該当するすべてのフェールオーバーマネージャーは、Postgresのマイナーバージョンのアップグレードを実行できます。

他のソフトウェアコンポーネントのマイナーアップグレードは、将来のリリースに追加される予定です。

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

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

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

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

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

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

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

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

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

  • M1 アーキテクチャの場合、この機能はそのすべてのアップグレードシナリオでサポートされています。

  • PGD-Always-ON/ BDR-Always-ON の場合、これはマイナーバージョンのアップグレード中に のみ サポートされています。

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

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

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

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

--xxx-package-version オプションpostgres、bdr、pglogicalなどを クラスター構成 に使用するか、config.ymlでxxx_package_version 変数を定義することにより、特定のバージョンを選択した場合、インストールされたパッケージが既に要件を満たしているため、アップグレードは何も行いません。要求されたバージョン。

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

$ tpaexec upgrade ~/clusters/speedy -vv         \
  -e postgres_package_version="2:11.6r2ndq1.6.13*"      \
  -e pglogical_package_version="2:3.6.11*"              \
  -e bdr_package_version="2:3.6.11*"

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

注 ワイルドカードの使用に関する既知の問題 のpackage_versionでのワイルドカードの使用の制限を参照してください。

要求したPostgres、PGD、およびpglogicalパッケージバージョンの組み合わせが賢明であることを確認するのはあなたの責任です。つまり、これらは連携して動作し、インストールしたものから新しいバージョンへのアップグレードパスが存在する必要があります。

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

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

目次