Upgrading your cluster ====================== ``tpaexec upgrade`` コマンドは、TPAクラスターで実行されているソフトウェアをアップグレードするために使用されます。 ``tpaexec deploy`` はアップグレードを実行しません。 このコマンドは、以前の\ ``tpaexec update-postgres`` コマンドを置き換えます。 .. Note:: TPAは、共有Barmanおよび/または共有PEM構成を持つクラスターでの`tpaexec upgrade` コマンドの使用をまだサポートしておらず、将来のリリースでこの機能を追加します。 .. :: ##はじめに config.ymlに変更を加えた場合、それらの変更を適用する方法は、\ ``tpaexec provision`` に続いて\ ``tpaexec deploy`` を実行することです。 このルールの例外は、 ``tpaexec deploy`` が既にインストールされているパッケージの別のバージョンのインストールを拒否することです。代わりに、\ ``tpaexec upgrade`` を使用してソフトウェアアップグレードを実行する必要があります。 次のコンポーネントは、 **任意の** アーキテクチャでアップグレードできます。 - Postgres - :ref:`Repmgrリダイレクトpgbouncer ` - :ref:`共有Barmanまたは共有PEMクラスター <共有Barmanまたは共有PEMクラスター>` - :ref:`PG Backup API ` - :ref:`共有Barmanまたは共有PEMクラスター <共有Barmanまたは共有PEMクラスター>` サーバーとエージェントの両方 次のコンポーネントは **M1** アーキテクチャでアップグレードでき、使用されるフェールオーバーマネージャーに応じて異なります。 - :ref:`efm-pre-config ` - :ref:`Patroni cluster management commands ` - :ref:`etcd ` パトローニ用 - :ref:`Repmgrリダイレクトpgbouncer ` 次のコンポーネントは、使用するBDRバージョンに応じて、 **BDR -Always-ON** / **PGD-Always-ON** アーキテクチャでアップグレードできます。 - :ref:`pgdcli ` BDR 4の場合はv1、PGD5の場合はv5 - :ref:`pgd-proxy-config ` PGD5のみ .. Note Minor version upgrades only:: **`tpaexec upgrade` は、Postgresおよびほとんどのクラスターコンポーネントのメジャーバージョンのアップグレードをサポートしていません** TPAがアップグレードできるものは、アーキテクチャによって異なります。 - 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 `` を実行して、標準のヘルスチェックを実行します。アップグレードプロセス自分自身はアップグレード前のヘルスチェックを実行しますが、事前に問題を検出すると、それに対処する時間が長くなります。 BDR対応アーキテクチャの場合、すべてのノードがカタログに表示されることも確認します。 .. code:: sql SELECT node_name, peer_state_name, peer_target_state_name FROM bdr.node_summary; すべてのエントリは\ ``ACTIVE`` または読み取り専用スタンバイの場合は\ ``STANDBY`` を報告する必要があります。続行する前に、他の状態を調査します。 repmgrを使用するM1クラスターの場合、プライマリで\ ``repmgr cluster show`` を実行し、すべてのノードが実行中および接続されていると表示されることを確認します。 バックアップの検証 ^^^^^^^^^^^^^^^^^^ アップグレードの前に、最近のBarmanバックアップが存在し、復元可能な状態にあることを確認してください。 Barmanホストの場合 .. code:: shell sudo -u barman barman list-backup sudo -u barman barman check ここで失敗したステータスは、開始する前に調査する必要があります。アップグレードが進行すると、 Barman WALレシーバーが停止されるため、アップグレードウィンドウ中のバックアップランドスケープは、事前に存在したものに固定されます。 レプリケーションラグの検証 ^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスターは高レベルで正常な場合がありますが、個々のレプリカは遅延している場合があります。アップグレードは、各インスタンスを順番にフェンスします。レプリカが大幅に遅れている場合、フェンスを解除した後に追いつくのに時間がかかり、全体のアップグレード時間が長くなります。 PGDクラスターの場合 .. code:: sql SELECT slot_name, active, restart_lsn, write_lag, flush_lag, replay_lag FROM bdr.node_slots; M1クラスターの場合、プライマリで .. code:: sql 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は各コンポーネントの利用可能な最新のパッケージをインストールします。これにより、意図しないメジャーバージョンのアップグレードが発生する可能性があります。 :ref:`パッケージバージョンの選択 <パッケージバージョンの選択>` を参照 詳細については。 .. Note:: `config.yml` のバージョンを更新した後、 `tpaexec provision` を実行してインベントリを再生成します。 .. :: ### リリースノートを読む アップグレードするすべてのコンポーネントのターゲットバージョンのリリースノートを確認しますが、現在のバージョンとターゲットバージョン間のリリースノートも確認します。 EDBのPGDおよびPostgresリリースノートでは、バージョン固有のアップグレードの考慮事項、つまりアップグレードの前後に変更する必要がある設定、非推奨、および動作の変更を呼びかけている場合があります。同じことは、アップグレードの実行に使用しているTPAの新しいバージョンのTPA独自のリリースノートにも適用されます。 ステージング環境でアップグレードをテストする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``tpaexec upgrade`` は、クラスターをインスタンスごとに処理します。アップグレードはローリング中です。一度に1つのインスタンスのみがフェンスオフされます。ただし、合計ウォールクロック時間は、クラスターサイズ、アップグレードするコンポーネントの数、各インスタンスのストレージとネットワークの特性だけでなく、アップグレードシナリオが問題なく完了するかどうかにも依存します。 実稼働クラスターのアーキテクチャ、Postgresのフレーバーとバージョン、パッケージのピン留め、およびカスタムフックと一致する非実稼働環境でアップグレードを再現することを強くお勧めします。これにより、ライブトラフィックに影響を与える前に、予期せぬ事態構成済みリポジトリ内のパッケージの欠落、予期しない構成のドリフトをキャッチします。 スケジュールされたジョブを無効にする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ アップグレードウィンドウ中にクラスターに対して実行されるようにスケジュールされているものはすべて一時停止する必要があります。代表的な商品 - データベースにヒットするCronジョブアナリティクス、レポート。 - アップグレードを認識しない外部バックアップツール。 - 長時間実行される移行またはバッチジョブ。 TPA自分自身は、開始する前にBarman WALレシーバーを停止し、その後再起動します。 Barmanを手動で無効にする必要はありません。 アップグレード中 ---------------- このセクションでは、\ ``tpaexec upgrade`` の実行中に予想されることと、TPAの外部から注意すべきことについて説明します。 予想されること ^^^^^^^^^^^^^^ TPAは、クラスターを一度に1インスタンスずつ処理します。インスタンスごとに、アップグレードは次のとおりです。 1. インスタンスをフェンスオフして、プロキシまたはフェールオーバーマネージャーが新しい接続の送信を停止します。 2. そのインスタンスで影響を受けるサービスを停止します。 3. 新しいパッケージをインストールします。 4. 必要に応じて構成ファイルを更新します。 5. サービスを再起動し、起動するまで待機します。 6. インスタンスのフェンスを解除します。 各インスタンスがフェンスされている間、およびサービスに戻ったときに、短い接続の中断が発生することを想定してください。接続プーリングと再試行ロジックを使用するアプリケーションは、通常、これらの移行中にクライアントに表示されるエラーを認識しないはずです。 非リーダーノードの各ノードがアップグレードされている間、書き込みトラフィックは、現在の書き込みリーダーを介して継続されます。書き込みリーダー自分自身がアップグレードされるたびに、短いリーダー選択の中断が発生します。 PGD-SおよびPGD-Xは、書き込みリーダーが最後にアップグレードされるように手配します。 PGD-Always-ONはインベントリの順序でノードをアップグレードするため、現在のリーダーの番が巡って来るたびにリーダー選挙が発生します。 アプリケーション側で見るべきもの ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ アップグレードの実行中、各フェンス/アンフェンスの移行で短い一時停止が発生するのは通常です。複数のインスタンスにわたる持続的な接続障害はそうではありません。これらが表示された場合は、TPAが次のインスタンスに進む前に停止して調査します。 アップグレード中にクラスターに対してアプリケーションが実行されている場合、以下を監視します。 - アプリケーションエラー率 一時的な再試行が予想されます。持続的なエラーはそうではありません。 - 接続プールメトリック 使用可能な接続の一時的な低下が予想されます。 - レプリケーションスロットの遅延 各インスタンスがアップグレード後に追いつくと、一時的に増加する場合があります。 アップグレード後 ---------------- このセクションでは、\ ``tpaexec upgrade`` が完了したら実行する必要がある検証について説明します。 インストールされたパッケージバージョンの確認 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 新しいパッケージがすべてのインスタンスにインストールされることを確認します。 RHELファミリーホストの場合 .. code:: shell tpaexec cmd all -m shell -a rpm -qa | grep -E "^(postgres|edb-)" Debian / Ubuntuホストの場合 .. code:: shell tpaexec cmd all -m shell -a dpkg -l | grep -E "(postgres|edb-)" 同じパッケージバージョンは、同じロールのすべてのインスタンスで報告される必要があります。 サービスとレプリケーションの検証 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ すべてのサービスが正常に再起動したことを確認します。 .. code:: shell tpaexec cmd all -m shell -a systemctl is-active postgres PGDクラスターの場合、 BDRが完全に再コンバートしたことを確認します。 .. code:: sql SELECT node_name, peer_state_name FROM bdr.node_summary; repmgrを使用したM1クラスターの場合 .. code:: shell tpaexec cmd role_primary -m shell -a repmgr -f /etc/repmgr.conf cluster show 新しいバックアップを取ります ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 重要なアップグレードの後、クラスターの新しいBarmanバックアップを取得します。 .. code:: shell tpaexec cmd role_barman -m shell -a sudo -u barman barman backup これにより、アップグレード後の状態を反映する既知の正常な復元ポイントが得られます。 スケジュールされたジョブを再度有効にする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ アップグレードの前にcronジョブ、バッチジョブ、または外部スケジュールされたタスクを無効にした場合、ここでそれらを再度有効にします。 TPA独自のBarman WALレシーバーは、自動的に再起動されます。 tpaexecテストを実行する ^^^^^^^^^^^^^^^^^^^^^^^ 最終的なスモークチェックとして、標準のテストスイートを実行します。 .. code:: shell tpaexec test これにより、接続、レプリケーション、ロールマッピング、およびアップグレード前に実行されたコンポーネント固有のチェックが実行されます。クリーンテストの実行は、アップグレードが完了したことの最も簡単なエンドツーエンドの確認です。 失敗したアップグレードからの復旧 -------------------------------- ``tpaexec upgrade`` が障害を報告した場合、クラスターは、障害が発生したときに処理されていたインスタンスで既知の状態のままです。後続のインスタンスはタッチされません。 ロールバックする場合、EDBサポートに電話する場合 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ロールバックは、TPAが不可逆的なカタログ変更を適用する前にのみ安全です。通常は、メジャーバージョンのアップグレードで発生するBDR側の構成の更新です。これらの変更が適用されると、正しいパスは逆方向ではなく前方になります。 続行するかロールバックするかがわからない場合は、停止してEDBサポートに連絡してください。 - 失敗した実行の\ ``ansible.log`` 。 - ``tpaexec test `` の出力。 - どのインスタンスがアップグレードを完了し、どのインスタンスが完了していないかの説明。 - 使用されるconfig.yml。 - オプションでEDB lassoレポートまたはその他の意味のあるログ。 よくある落とし穴 ---------------- このセクションには、過去にユーザーを魅了したいくつかの特定の状況が統合されています。 固定されたパッケージバージョンによりno-opアップグレードが発生する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``postgres_package_version`` または他の\ ``xxx_package_version`` がインストールされたパッケージと既に一致する場合、 ``tpaexec upgrade`` はコンポーネントを「既に目的のバージョン」として報告し、何も行いません。この症状は、実行が変更なしですぐに完了し、目的のバージョンがインストールされていないことです。 修正 ``config.yml`` を更新して目的の新しいバージョンを設定し、 ``tpaexec provision`` 、続いて\ ``tpaexec upgrade`` を再実行します。詳細は、 :ref:`パッケージバージョンの選択 <パッケージバージョンの選択>` を参照してください。 共有Barmanまたは共有PEMクラスター ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TPAは、現在、共有Barmanまたは共有PEM構成を使用するクラスターに対する\ ``tpaexec upgrade`` の実行をサポートしていません。この制限は、早期に中止されるアップグレードの前提条件によって適用されます。サポートが追加されるまで、これらのクラスターシェイプのアップグレードはTPAの外部で手動で実行する必要があります。 :ref:`After a manualmajor-version Postgres upgrade ` を参照してください その後にクラスターを調整する方法については。 コンポーネントの選択 -------------------- .. Note:: コンポーネントのアップグレードは厳密にオプトインです .. :: デフォルトでは、 `--components` フラグが渡されない場合、`tpaexec upgrade` はPostgresを単独で更新します .. code:: shell tpaexec upgrade ~/clusters/speedy 更新する特定のコンポーネントを選択するために、\ ``--components`` フラグはコンマ区切りリストを取ります .. code:: shell tpaexec upgrade ~/clusters/speedy \ --components=postgres,pgd-proxy,pgdcli,pgbouncer,pg-backup-api,barman クラスター内の該当するすべてのコンポーネントを更新する必要がある場合は、\ ``all`` をフラグに渡すことができます .. code:: shell tpaexec upgrade --components=all .. csv-table:: :header: component,value,architecture :widths: 12,25,15 :align: left :class: longtable 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`` はインストールされたパッケージの最新の利用可能なバージョンに更新します。 .. Note Minor upgrade is not strictly enforced:: アップグレード時に目的のパッケージバージョンが提供されない場合、TPAは使用可能な最新のパッケージをインストールします。マイナーバージョンの制限は、tpaexecのアップグレード中に厳密に適用されません。これにより、コンポーネントのサポートされていないメジャーアップグレードを不本意に試行する可能性があります。したがって、アップグレードのバージョンを明示的に選択して、既存のクラスターでの互換性を保証することをお勧めします。メジャーバージョンは完全に別のパッケージであり、これが発生しないようにするため、Postgresはこの問題を提起しません。 .. :: `--xxx-package-version` オプションpostgres、bdr、pglogicalなどを :ref:`クラスター構成 <クラスター構成>` に使用するか、config.ymlで`xxx_package_version` 変数を定義することにより、特定のバージョンを選択した場合、インストールされたパッケージが既に満足しているため、アップグレードは何も行いません要求されたバージョン。 この場合、config.ymlを編集し、バージョン設定を更新し、\ ``tpaexec provision`` を再実行する必要があります。更新により、選択したバージョンのパッケージがインストールされます。以下に示すように、コマンドラインでバージョンを指定することにより、特定のバージョンに更新することもできます。 .. code:: shell 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*`` のみを理解します上記の例のように。 .. Note : see limitations of using wildcards in package_version in:: :ref:`ワイルドカードの使用に関する既知の問題 <ワイルドカードの使用に関する既知の問題>` 。 .. :: 要求したPostgres、PGD、およびpglogicalパッケージバージョンの組み合わせが賢明であることを確認するのはあなたの責任です。つまり、これらは連携して動作し、インストールしたものから新しいバージョンへのアップグレードパスが存在する必要があります。 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`` を実行します。 .. code:: shell tpaexec reconfigure ~/clusters/speedy\ --architecture PGD-Always-ON\ --pgd-proxy-routing local このコマンドは、config.ymlを読み取り、クラスターをアップグレードするために必要な変更を行い、新しいconfig.ymlを書き込みます。呼び出しの詳細については、 :ref:`tpaexec reconfigure ` を参照してください。変更を確認した後、\ ``tpaexec upgrade`` を実行してアップグレードを実行します。 .. code:: shell tpaexec upgrade ~/clusters/speedy\ または、プロキシモニタリングを有効にしてアップグレードを実行するには、 .. code:: shell 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`` ロールと同じインスタンスにあります。スタンドアロンプロキシインスタンスが存在すると、\ ``switch2cm`` コマンドが中止されます。移行を続行する前に、クラスターからスタンドアロンプロキシインスタンスを削除する必要があります。 ステージ1ビルトイン接続マネージャーへの移行 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 最初のステージは、 ``PGD 5.9+`` クラスターを再構成して、外部\ ``pgd-proxy`` の使用から最新のビルトイン\ ``Connection Manager`` に切り替えることです。 TPAは、 ``tpaexec switch2cm`` コマンドを提供して、最小限のダウンタイムでこの移行を自動化します。 .. Note Transitional State Only:: このプロセスは、 `PGD 6` にアップグレードする前の中間ステップとしてのみを目的とした過渡的な`PGD 5.9+` クラスター状態を作成します。 TPAは現在、`Connection Manager` を有効にして`PGD5.9+` に滞在すること、またはこの構成で`PGD5.9+` の新しいマイナーバージョンへの移動をサポートしていません。将来のTPAリリースは、 `Connection Manager` による`PGD 5` のライフサイクル管理を完全にサポートします。 .. :: #### ステップ1.1接続マネージャー用に再構成する 次のコマンドを実行して、\ ``config.yml`` ファイルを更新します。これにより、ビルトイン\ ``Connection Manager`` を有効にするために必要な設定が追加されます。 **このアクションは構成ファイルのみを変更します。データベースクラスターの実行状態はまだ変更されません。** 新しいバージョンを書き込む前に、\ ``reconfigure`` は、現在のファイルたとえば ``config.yml.~1~`` のバックアップを自動的に保存し、安全な復元ポイントを提供します。 呼び出しの詳細については、 :ref:`tpaexec reconfigure ` を参照してください。 .. code:: shell tpaexec reconfigure ~/clusters/speedy --enable-connection-manager ステップ1.2接続マネージャーに切り替える ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``tpaexec switch2cm`` コマンドを実行して、\ ``pgd-proxy`` からビルトイン\ ``Connection Manager`` への移行を実行します。このコマンドは、 ``tpaexec provision`` を自動的に実行してAnsibleインベントリーを更新し、最小限のダウンタイムですべてのノードをスイッチします。 .. code:: shell tpaexec switch2cm ~/clusters/speedy ``switch2cm`` コマンドは、次の操作を実行します。 1. 接続マネージャー設定でAnsibleインベントリーを更新します 2. 各ノードごと - ノードをフェンスして新しい接続を防止します - PostgreSQLを再起動して接続マネージャー構成をロードします - ``pgd-proxy`` サービスを停止します - PostgreSQLを再度起動して接続マネージャーがポートをバインドできるようにしますb_tran_7 接続マネージャーがリッスンを開始するのを待機します - ノードのフェンスを解除し、接続を確認します このプロセスは、公式 :ref:`EDB Connection Manager Migrationprocedure ` に従います。 ステージ1完了 ^^^^^^^^^^^^^ このステージの最後に、ビルトイン\ ``Connection Manager`` で実行される\ ``PGD`` クラスターが作成されます。これは中間状態であり、ステージ2に直接進む必要があります。マイナーバージョンアップグレードの\ ``tpaexec upgrade`` は、この中間状態では **サポートされていません** が、 PGD 6へのアップグレードが完了するまで\ ``tpaexec deploy`` を実行することをお勧めします。 ステージ2アーキテクチャのPGD-Xへのアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスターが\ ``Connection Manager`` で実行されたら、最後の構成手順に進んで、\ ``PGD 6`` アップグレードの準備をできます。 .. Note:: `Stage 1` が正常に完了し、ビルトイン`Connection Manager` で実行されているクラスターからこのプロセスを開始する必要があります。 .. :: #### ステップ2.1 PGD-Xアーキテクチャ用に再構成する 次のコマンドを実行して、新しいアーキテクチャに合わせて\ ``config.yml`` を更新します。これにより、クラスターアーキテクチャタイプが変更され、\ ``BDR`` バージョンが6に設定され、古い古い設定が削除されます。 **このアクションは構成ファイルのみを変更します。データベースクラスターの実行状態はまだ変更されません。** .. code:: shell tpaexec reconfigure ~/clusters/speedy --architecture PGD-X ステップ2.2ソフトウェアのアップグレードを実行する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``config.yml`` の最終的な変更を確認した後、標準の\ ``tpaexec upgrade`` コマンドを実行できます。これにより、すべてのノードでソフトウェアのアップグレードが実行され、クラスターが\ ``PGD 6`` になります。 .. code:: shell tpaexec upgrade ~/clusters/speedy または、プロキシモニタリングを有効にしてアップグレードを実行するには、 .. code:: shell 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-SまたはPGD-X ---------------- 既存のPGD6 PGD-SまたはPGD-Xクラスターを最新の利用可能なソフトウェアバージョンにアップグレードする場合、アップグレードプロセスは次を実行します。 1. クラスターが正常であること、およびノードが構成済みのポートでリッスンしていることを確認します。 2. アップグレードするノードにローカルリポジトリを含むリポジトリが構成および更新されていることを確認します。 3. 更新されたパッケージをインストールできることの確認 4. クラスター内の各BDRノードを一度に1つずつアップグレードします。 **重要:** 高可用性を保証するために、書き込みリーダーがアップグレードされるノードの中にある場合、アップグレードされる最後のノードになります。 - 接続を受け入れないようにノードをフェンスします - postgres - postgresと更新PGDパッケージ - ノードのフェンスを解除して、接続を再度受信できるようにします - BDRクラスターが再確立されたことを確認します Raftコンセンサス使用b_tran_6 アップグレードされたノードが構成済みのポートでリッスンしていることを確認します 1. クラスターヘルスチェックを再実行します 2. アップグレードされたパッケージに関する情報を出力します PGD-Always-ON ------------- 既存のPGD-Always-ON PGD5クラスターを最新の利用可能なソフトウェアバージョンにアップグレードする場合、アップグレードプロセスは次を実行します。 1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。 2. クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します 3. クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。 4. 選択したすべてのコンポーネントを目的のバージョンに更新できることを確認しますパッケージバージョンが提供されている場合 5. クラスター内のBDRノードごとに、一度に1つずつ - pgd-proxyが接続を送信しないようにノードをフェンスオフします。 - postgresを停止、更新、および再起動します。 - ノードのフェンスを解除しますので、 - pgd-proxyおよびpgd-cliソフトウェアの更新明示的にオプトインした場合 6. クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って 7. 必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合 BDR-Always-ON ------------- BDR-Always-ONクラスターの場合、アップグレードプロセスはクラスターインスタンスを1つずつ実行し、次のことを実行します。 1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。 2. クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します 3. クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。 4. サーバーがメンテナンス中であることをhaproxyに伝えます。 5. インスタンスがアクティブサーバーの場合、pgbouncerに再接続し、アクティブなセッションが閉じられるまで待機するように要求します。 6. Postgresを停止し、 Postgres、etcd、およびpgdcli該当する場合およびオプトインの場合パッケージを更新し、Postgresを再起動します。 7. 最後に、haプロキシを介して要求を受信するためにサーバーを再度「準備ができている」としてマークします。 8. クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って 9. 必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合 PGD論理スタンバイまたは物理レプリカインスタンスは、haproxyまたはpgbouncerの相互作用なしで更新されます。クラスター内の非Postgresインスタンスは放置されます。 M1 -- M1クラスターの場合、\ ``upgrade`` は最初にストリーミングレプリカと監視ノードを更新し、次に :ref:`tpaexec switchover ` プライマリからアップグレードされたレプリカのいずれかに移行し、プライマリを更新し、最初のプライマリノードにスイッチオーバーします。 1. クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。共有PEMまたは共有Barmanクラスターではないことを含みます。 2. クラスターに適用されるすべてのコンポーネントのアップグレード前ヘルスチェックを実行します。進行中のBarmanバックアップがないことを含む、これによりWALレシーバーが停止します 3. クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらの中で利用可能なことを確認します。 4. ストリーミングレプリカと監視のPostgresを更新します。ノード該当する場合 5. プライマリからアップグレードされたレプリカのいずれかに :ref:`tpaexec switchover ` を実行します 6. プライマリでPostgresを更新する 7. 最初のプライマリノードにスイッチオーバーします。 8. クラスター内の該当ノードの場合、pgbouncer、barman、pg-backup-api、およびPEMエージェント/PEMサーバーを更新しますノードのロールに従って 9. 必要に応じてBarman WALレシーバーを起動し、すべてのコンポーネントのアップグレード後のヘルスチェックを実行しますクラスターに適用される場合 アップグレードプロセスの制御 ---------------------------- ``update_hosts`` 変数を定義することにより、クラスターのインスタンスがアップグレードされる順序を制御できます。 .. code:: shell tpaexec upgrade ~/clusters/speedy \ -e update_hosts=quirk,keeper,quaver これは、シャドウサーバーが最初にアップグレードされるように、アクティブなPGDプライマリインスタンスを最後にリストすることにより、アップグレード中のリード/シャドウのスイッチオーバーを最小限に抑えるのに役立つ場合があります。 環境で追加のアクションが必要な場合、 :ref:`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つはリーダー自分自身を書き込みます。これらのアーキテクチャでリーダー-最後のシーケンスを達成するために追加の手順は必要ありません。