tpaexec rehydrate ================= ``tpaexec rehydrate`` コマンドは、更新されたマシンイメージ（AMI）でAWS EC2インスタンスをリビルドし、TPAによって管理されるクラスターへのセキュリティパッチとOSアップグレードの迅速なデプロイを可能にします。 必要な変更がすべて含まれた新しいAMIを指定すると、このコマンドはインスタンスを終了し、新しいイメージを使用する新しくプロビジョニングされたインスタンスに置き換え、サーバーの構成を正確に再作成する前に、古いインスタンスからデータボリュームをアタッチします（に基づいて\ ``config.yml`` ）。 最新のイメージを公開し、定期的にサーバーをゼロから再構築することを要求することは、一連のサーバーが個々のセキュリティ更新を自分でダウンロードしてインストールできるようにする代わりの方法です。これにより、各サーバーの状態を一目で追跡しやすくなり、個々のサーバーへの手動変更をお勧めしません（インスタンスの置換中に消去されます）。 TPAを使用すると、リハイドレーション中のクラスター全体の中断を簡単に最小限に抑えることができますが、プロセスには個々のサーバーが終了して置き換えられるためのダウンタイムが必然的に伴う必要があります。 :ref:`streaming replication cluster ` では、最初にレプリカをリハイドレートしてから :ref:`tpaexec switchover ` を使用できます リハイドレートする前にプライマリをレプリカに変換します。 :ref:`BDR-Always-ON clusters ` では、リハイドレートする前に\ `remove each server from the haproxy server pool `__\ し、その後に追加し直すことができます。 Postgresおよび関連するコンポーネントにマイナーバージョンの更新をインストールしたいだけの場合は、代わりに :ref:`tpaexec upgrade ` コマンドを使用できます。 前提条件 -------- インスタンスをリハイドレートできるようにするには、 ``config.yml`` 内のそのデータボリュームごとに\ ``delete_on_termination: no`` および\ ``attach_existing: yes`` を指定する必要があります。 （新しいインスタンスには必ず新しいEBSルートボリュームがあります。） デフォルトでは、EC2インスタンスを終了すると、それにアタッチされたEBSボリュームも終了します。この場合、新しいインスタンスに再接続したいため、 ``delete_on_termination`` を無効にする必要があります。 ``attach_existing`` を設定すると、新しいインスタンスをプロビジョニングするときにTPAが古いボリュームを検索し、見つかった場合は実行後にインスタンスにアタッチします。 古いインスタンスを手動で停止または終了しないでください。 ``tpaexec rehydrate`` コマンドは、インスタンスを安全にリハイドレートできることを確認した後、これを行います。 例 -- ``~/clusters/night`` にAWSクラスター構成があるとします。 構成を変更する ^^^^^^^^^^^^^^ まず、 ``config.yml`` を編集し、新しいAMIを指定する必要があります。例： .. code:: yaml ec2_ami: Name: RHEL-8.3_HVM-20210209-x86_64-0-Hourly2-GP2 Owner: 309956199498 データボリュームごとに\ ``delete_on_termination`` が無効になっていることを確認します。パラメータが存在しない場合、AWS EC2マネジメントコンソールからその値を確認できます。 [Instances]をクリックし、インスタンスを選択してから、[Description]タブを開き、[Block devices]までスクロールダウンして、EBSボリュームをクリックします。 「終了時に削除」フラグがtrueに設定されている場合、 :ref:`change it using `awscli` <#appendix>` できます。また、 ``attach_existing`` を確認し、まだ設定されていない場合は\ ``yes`` に設定します。 両方の属性が正しく設定された例を次に示します。 .. code:: yaml instances: - node: 1 Name: vlad subnet: 10.33.14.0/24 role: primary volumes: - device_name: /dev/xvdf volume_type: gp2 volume_size: 16 attach_existing: yes delete_on_termination: false vars: volume_for: postgres_data mountpoint: /var/lib/pgsql （ボリュームパラメーターは、特定のインスタンスだけでなく\ ``instance_defaults`` でも設定できることに注意してください。 ``volumes:`` を検索し、関連するすべてのボリュームにこれら2つの属性が設定されていることを確認してください。） 水分補給を開始する ^^^^^^^^^^^^^^^^^^ これは、 rehydrate コマンドの構文です。 .. code:: bash $ tpaexec rehydrate ~/clusters/night instancename 単一のインスタンス名またはインスタンス名のコンマ区切りリストを指定できます（ただし、クラスター内のすべてのインスタンスを一度にリハイドレートすることはできません）。 このコマンドは、最初に、リハイドレートされるインスタンスにアタッチされているすべての非ルートEBSボリュームの\ ``delete_on_termination`` フラグがfalseに設定されていることを確認します。そうでない場合、インスタンスが終了する前にエラーで停止します。 ボリューム属性が正しく設定されている場合、コマンドは最初に各インスタンスを終了し、プロビジョニングとデプロイを実行して、新しいAMIを使用して新しいインスタンスに置き換えます。 段階的に水分を補給する ---------------------- クラスターの継続性を維持するには、クラスターを段階的にリハイドレートすることをお勧めします。 たとえば、プライマリインスタンス、2つのレプリカ、およびBarmanバックアップサーバーを備えた :ref:`cluster that uses streaming replication ` では、 Barmanインスタンスと1つのレプリカを最初にリハイドレートし、次に別のレプリカをリハイドレートし、次にプライマリからリハイドレートされたレプリカの1つに :ref:`スイッチオーバー <スイッチオーバー>` し、前者をリハイドレートできます。プライマリ、および（オプションで）元のプライマリにスイッチオーバーします。このシーケンスにより、1つのプライマリと1つのレプリカが常に利用可能になります。 付録 ---- awscliを使用してボリューム属性を変更する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ まず、AWSマネジメントコンソールでインスタンスとEBSボリュームを見つけます。 [インスタンス]をクリックしてインスタンスを選択し、[説明]タブを開き、[デバイスのブロック]までスクロールダウンして、EBSボリュームを選択します。 ``delete_on_termination`` を無効にするには、 ``--region`` 、\ ``--instance-id`` 、およびブロックデバイス名を正しい値に置き換えた後、次のコマンドを実行します。 .. code:: bash $ aws ec2 modify-instance-attribute \ --region eu-west-1 --instance-id i-XXXXXXXXXXXXXXXXX \ --block-device-mappings \ [{"DeviceName": "/dev/xvdf", "Ebs": {"DeleteOnTermination": false}}] インスタンスのデータボリュームごとにこれを行います。少し遅れて、管理コンソールで変更を確認できるはずです。 ``tpaexec rehydrate`` は、インスタンスを安全にリハイドレートできることも検出します。