tpaexec rehydrate¶

tpaexec rehydrate コマンドは、更新されたマシンイメージ（AMI）でAWS EC2インスタンスをリビルドし、TPAで管理されるクラスターにセキュリティパッチとOSアップグレードを迅速にデプロイできます。

必要な変更がすべて含まれた新しいAMIを指定すると、このコマンドはインスタンスを終了し、新しいイメージを使用する新しくプロビジョニングされたインスタンスに置き換え、サーバーの構成を正確に再作成する前に古いインスタンスからデータボリュームをアタッチします（ config.yml ）。

最新のイメージを公開し、定期的にサーバーをゼロから再構築することを要求することは、一連のサーバーが自分自身で個々のセキュリティ更新をダウンロードしてインストールすることを許可することに代わるものです。これにより、各サーバーの状態を一目で追跡しやすくなり、個々のサーバーへの手動変更はお勧めしません（インスタンスの置換中に消去されます）。

TPAを使用すると、リハイドレート中のクラスター全体の中断を簡単に最小限に抑えることができますが、プロセスには個々のサーバーが終了して置き換えられるためのダウンタイムが必然的に含まれます。: streaming replication cluster では、最初にレプリカをリハイドレートしてから tpaexec switchover

を使用できます

リハイドレートする前にプライマリをレプリカに変換します。 BDR-Always-ON clusters では、リハイドレートする前に remove each server from the haproxy server pool 、その後に追加できます。

Postgresおよび関連するコンポーネントのマイナーバージョンの更新をインストールするだけの場合は、代わりに: tpaexec update-postgres コマンドを使用できます。

前提条件¶

インスタンスをリハイドレートできるようにするには、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を指定する必要があります。例：

ec2_ami:
  Name: RHEL-8.3_HVM-20210209-x86_64-0-Hourly2-GP2
  Owner: 309956199498

各データボリュームのdelete_on_termination が無効になっていることを確認します。パラメータが存在しない場合、AWS EC2マネジメントコンソールからその値を確認できます。 [インスタンス]をクリックしてインスタンスを選択し、[説明]タブを開き、[デバイスのブロック]までスクロールして、EBSボリュームをクリックします。「終了時に削除」フラグがtrueに設定されている場合、 change it using `awscli <#appendix>` できます。また、 attach_existing を確認し、まだ設定されていない場合はyes に設定します。

両方の属性が正しく設定された例を次に示します。

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コマンドの構文です。

$ tpaexec rehydrate ~/clusters/night instancename

単一のインスタンス名またはインスタンス名のコンマ区切りリストを指定できます（ただし、クラスター内のすべてのインスタンスを一度にリハイドレートすることはできません）。

このコマンドは、最初に、リハイドレートされるインスタンスにアタッチされたすべての非ルートEBSボリュームのdelete_on_termination フラグがfalseに設定されていることを確認します。そうでない場合、インスタンスが終了する前にエラーで停止します。

ボリューム属性が正しく設定されている場合、コマンドは最初に各インスタンスを終了し、プロビジョニングとデプロイを実行して、新しいAMIを使用して新しいインスタンスに置き換えます。

段階的に水和¶

クラスターの連続性を維持するには、クラスターを段階的にリハイドレートすることをお勧めします。

たとえば、プライマリインスタンス、2つのレプリカ、およびBarmanバックアップサーバーを備えたcluster that uses streaming replicationでは、最初にBarmanインスタンスと1つのレプリカをリハイドレートし、次に別のレプリカをリハイドレートし、プライマリからリハイドレートされたレプリカの1つに tpaexec switchover をリハイドレートできます。プライマリ、および（オプションで）元のプライマリにスイッチオーバーします。このシーケンスにより、1 つのプライマリと 1 つのレプリカが常に使用可能になります。

付録¶

awscliを使用してボリューム属性を変更する¶

まず、AWS マネジメントコンソールでインスタンスと EBS ボリュームを見つけます。 [インスタンス]をクリックしてインスタンスを選択し、[説明]タブを開き、[デバイスのブロック]までスクロールして、EBSボリュームを選択します。 delete_on_termination を無効にするには、 --region 、--instance-id 、およびブロックデバイス名を正しい値に置き換えた後、次のコマンドを実行します。

$ aws ec2 modify-instance-attribute \
    --region eu-west-1 --instance-id i-XXXXXXXXXXXXXXXXX \
    --block-device-mappings \
      [{"DeviceName": "/dev/xvdf", "Ebs": {"DeleteOnTermination": false}}]

インスタンスのデータボリュームごとにこれを行います。少しすると、管理コンソールで変更が表示されます。tpaexec rehydrate は、インスタンスを安全にリハイドレートできることも検出します。