Upgrading your cluster ====================== ``tpaexec upgrade`` コマンドは、TPAクラスターで実行されているソフトウェアをアップグレードするために使用されます（\ ``tpaexec deploy`` はアップグレードを実行しません）。 (このコマンドは、以前の\ ``tpaexec update-postgres`` コマンドに代わるものです。) はじめに -------- config.ymlに変更を加えた場合、それらの変更を適用する方法は、 ``tpaexec provision`` を実行してから\ ``tpaexec deploy`` を実行することです。 この規則の例外は、 ``tpaexec deploy`` は、既にインストールされているパッケージの別のバージョンのインストールを拒否することです。代わりに、 ``tpaexec upgrade`` を使用してソフトウェアのアップグレードを実行する必要があります。 このコマンドは、クラスター操作の中断を最小限に抑えてアップグレードの実行を試みます。以下に文書化されているように、特殊なアップグレードプロセスの正確な詳細は、クラスターのアーキテクチャによって異なります。 アップグレードするときは、アップグレードを開始する前に常にbarmanを使用してバックアップを取得し、アップグレードのために確保された時間中に行われるスケジュールされたバックアップを無効にする必要があります。 一般に、TPAはインスタンスごとに続行し、影響を受けるサービスを停止し、新しいパッケージをインストールし、必要に応じて構成を更新し、サービスを再起動し、ランタイム構成の変更を実行してから、次のインスタンスで同じことを行います。プロセス中はいつでも、クラスターのノードの1つだけが使用できなくなります。 クラスターをPGD-Always-ONにアップグレードする場合、または既存のPGD-Always-ONクラスターをアップグレードする場合、 ``-e enable_proxy_monitoring=true`` オプションを\ ``tpaexec upgrade`` コマンドラインに追加することにより、アップグレード中にプロキシノードのステータスの監視を有効にできます。有効にすると、これにより 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（つまり、 BDR4から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`` を自動的に実行して、アンシブルインベントリを更新します。アップグレードプロセスは次のことを行います。 1.クラスターをアップグレードするためのすべての前提条件が満たされていることを確認します。 2.クラスター内の各インスタンスについて、正しいリポジトリが構成されていること、および必要なpostgresパッケージがそれらで利用可能であることを確認します。 3. クラスター内の各BDRノードについて、一度に1つずつ： - ノードをフェンスして、 harp-proxyが接続を送信しないようにします。 - 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`` は最初にストリーミングレプリカを1つずつ更新し、次に :ref:`スイッチオーバー <スイッチオーバー>` プライマリからレプリカの1つに、プライマリを更新し、再度スイッチオーバーします。 パッケージバージョンの選択 -------------------------- デフォルトでは、クラスターの作成時にパッケージバージョン（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環境でアップグレードをテストすることを強くお勧めします。