tpaexec rehydrate ================= ``tpaexec rehydrate`` コマンドは、更新されたマシンイメージAMIでAWS EC2インスタンスを再構築し、TPAによって管理されるクラスターにセキュリティパッチとOSアップグレードを迅速に展開できます。 必要な変更をすべて備えた新しいAMIが与えられると、このコマンドはインスタンスを終了し、新しいイメージを使用する新しくプロビジョニングされたインスタンスに置き換え、サーバーの構成を正確に再作成する前に古いインスタンスからデータボリュームを接続します\ ``config.yml`` )。 最新のイメージを公開し、定期的なスケジュールでサーバーをスクラッチから再構築することは、サーバーフリートに個々のセキュリティ更新を自分自身でダウンロードしてインストールできるようにするための代替手段です。これにより、各サーバーの状態を一目で追跡することが簡単になり、個々のサーバーへの手動変更を防ぎますインスタンスの置換中に一掃されます。 TPAを使用すると、リハイドレーション中にクラスター全体の中断を最小限に抑えることが簡単になりますが、プロセスには、個々のサーバーが終了および置き換えられるときに必然的にダウンタイムが含まれる必要があります。 :ref:`M1 ` では、最初にレプリカをrehydrateから、 :ref:`tpaexec switchover ` を使用できます リハイドレートする前にプライマリをレプリカに変換します。 :ref:`BDR-Always-ON ` では、リハイドレートする前に :ref:`BDR/HAProxy server pool management ` を実行し、後で追加して戻すことができます。 Postgresおよび関連コンポーネントのマイナーバージョンの更新をインストールするだけの場合は、代わりに :ref:`Upgrading your cluster ` コマンドを使用できます。 前提条件 -------- インスタンスをrehydrateできるようにするには、 ``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ボリュームをクリックします。 “Delete on termination”フラグがtrueに設定されている場合、 :ref:`付録 <付録>` ことができます。また、 ``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 単一のインスタンス名またはインスタンス名のコンマ区切りリストを指定できますが、クラスター内のすべてのインスタンスを一度にrehydrateことはできません。 このコマンドは、リハイドレートされるインスタンスに接続されているすべての非ルートEBSボリュームの\ ``delete_on_termination`` フラグがfalseに設定されていることを確認します。これに当てはまらない場合、インスタンスが終了する前にエラーで停止します。 ボリューム属性が正しく設定されている場合、コマンドは最初に各インスタンスを終了し、次にプロビジョニングと展開を実行して、新しいAMIを使用する新しいインスタンスに置き換えます。 段階的に水分補給する -------------------- クラスターの継続性を維持するために、クラスターを段階的にリハイドレートすることをお勧めします。 たとえば、プライマリインスタンス、2つのレプリカ、およびBarmanバックアップサーバーを備えた :ref:`M1 ` では、最初にBarmanインスタンスと1つのレプリカをrehydrate、次に別のレプリカをリハイドレートし、次に :ref:`tpaexec switchover ` プライマリからリハイドレートしたレプリカのいずれかに、前者をrehydrateますプライマリ、およびオプションで元のプライマリにスイッチオーバーします。このシーケンスにより、1つのプライマリと1つのレプリカが常に利用できるようになります。 付録 ---- awscliを使用してボリューム属性を変更する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 最初に、AWS管理コンソールでインスタンスとEBSボリュームを見つけます。 ’Instances’をクリックしてインスタンスを選択し、[Description]タブを開いて[Block devices]までスクロールし、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`` は、インスタンスを安全にリハイドレートできることも検出します。