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および関連するコンポーネントにマイナーバージョンの更新をインストールしたいだけの場合は、代わりに: remove each server from the haproxy server pool コマンドを使用できます。

前提条件¶

インスタンスをリハイドレートできるようにするには、 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マネジメントコンソールからその値を確認できます。 [Instances]をクリックし、インスタンスを選択してから、[Description]タブを開き、[Block devices]までスクロールダウンして、EBSボリュームをクリックします。「終了時に削除」フラグがtrueに設定されている場合、 tpaexec upgrade できます。また、 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つに change it using `awscli <#appendix>` 、前者をリハイドレートできます。プライマリ、および（オプションで）元のプライマリにスイッチオーバーします。このシーケンスにより、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 は、インスタンスを安全にリハイドレートできることも検出します。