Upgrading your cluster ====================== ``tpaexec upgrade`` コマンドは、TPAクラスターで実行されているソフトウェアをアップグレードするために使用されます。 ``tpaexec deploy`` はアップグレードを実行しません。 このコマンドは、以前の\ ``tpaexec update-postgres`` コマンドを置き換えます。 はじめに -------- config.ymlに変更を加えた場合、それらの変更を適用する方法は、\ ``tpaexec provision`` に続いて\ ``tpaexec deploy`` を実行することです。 このルールの例外は、 ``tpaexec deploy`` が既にインストールされているパッケージの別のバージョンのインストールを拒否することです。代わりに、\ ``tpaexec upgrade`` を使用してソフトウェアアップグレードを実行する必要があります。 !!!注 ``upgrade`` で何ができますか? ``upgrade`` コマンドのサポートされている使用は次のとおりです。 - ``config.yml`` を変更せずにPostgresおよびその他のクラスターコンポーネントを最新のマイナーバージョンにアップグレードする - ``config.yml`` を変更して指定された新しいマイナーバージョンへのコンポーネントのアップグレード - ``reconfigure`` コマンドと組み合わせて、 Postgres Distributedのメジャーバージョンのアップグレードを実行します。 **アップグレードは、Postgresのメジャーバージョンのアップグレードをサポートしていません。** .. :: このコマンドは、クラスター操作の中断を最小限に抑えてアップグレードを実行しようとします。特殊なアップグレードプロセスの正確な詳細は、以下に文書化されているように、クラスターのアーキテクチャによって異なります。 アップグレードするときは、アップグレードを開始する前に常に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を書き込みます。呼び出しの詳細については、 :ref:`the command's own documentation ` を参照してください。変更を確認した後、\ ``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-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インスタンスは放置されます。 ``update_hosts`` 変数を定義することにより、クラスターのインスタンスが更新される順序を制御できます。 :: $ tpaexec upgrade ~/clusters/speedy \ -e update_hosts=quirk,keeper,quaver これは、シャドウサーバーが最初に更新されるように、アクティブなPGDプライマリインスタンスを最後にリストすることにより、更新中のリード/シャドウのスイッチオーバーを最小限に抑えるのに役立つ場合があります。 環境で追加のアクションが必要な場合、 :ref:`postgres-pre-update and postgres-post-update hooks ` パッケージのインストール手順の前後にカスタムAnsibleタスクを実行できます。 M1 -- !!!警告 M1の\ ``upgrade`` コマンドは既知のバグの影響を受けており、フェールオーバーマネージャーがPatroniまたはEFMの場合に失敗します。 TPAは、将来のリリースでM1の完全なアップグレード機能を提供します。 .. :: M1クラスターの場合、`upgrade` は最初にストリーミングレプリカを1つずつ更新し、次に :ref:`tpaexec switchover ` プライマリからレプリカのいずれかに接続し、プライマリを更新して、再びスイッチオーバーします。 パッケージバージョンの選択 -------------------------- デフォルトでは、クラスターを作成したときにパッケージバージョンPostgres、PGD、またはpglogicalなどを明示的に指定しなかった場合、\ ``tpaexec upgrade`` はインストールされたパッケージの最新の利用可能なバージョンに更新します。 ``--xxx-package-version`` オプションpostgres、bdr、pglogicalなどを :ref:`tpaexec configure ` に使用するか、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*`` のみを理解します上記の例のように。 注 :ref:`tpaexec-configure ` のpackage_versionでのワイルドカードの使用の制限を参照してください。 要求したPostgres、PGD、およびpglogicalパッケージバージョンの組み合わせが賢明であることを確認するのはあなたの責任です。つまり、これらは連携して動作し、インストールしたものから新しいバージョンへのアップグレードパスが存在する必要があります。 PGDクラスターの場合、パッケージマネージャーの依存関係の解決に依存して正しい依存関係を選択するのではなく、3つのコンポーネントすべてPostgres、PGD、pglogical の正確なバージョンを明示的に指定することをお勧めします。 運用環境で実行する前に、QA環境でアップグレードをテストすることを強くお勧めします。