テストは時間のかかる作業ですが、テクノロジーのアップグレードプロセスの前に行う必要があります。アップグレードの種類によっては、難しい場合もあれば簡単な場合もありますが、データの安全性を確保したい場合は常に必要です。ビジネスとダウンタイムの許容度に応じて、アップグレードにはさまざまなアプローチがあります。たとえば、プロセスが新しいバージョンの別の環境でアプリケーションをテストしている可能性があるため、このために新しいクラスターを作成する必要があります。もう1つのオプションは、現在の本番環境のクローンを作成してアップグレードすることです。これは、すべてのアップグレードプロセスをエミュレートし、将来の予期しない事態を回避できるため便利です。
このすべてのテストプロセスを手動で実行すると、人為的エラーが発生する可能性が高くなり、プロセスが遅くなり、目標復旧時間（RTO）に影響を与える可能性があります。このブログでは、ClusterControlを使用してPostgreSQLデータベースをアップグレードするためのテストを自動化する方法を説明します。
アップグレードには、マイナーアップグレードとメジャーアップグレードの2種類があります。
これは最も一般的で安全なアップグレードであり、ほとんどの場合、これは適切に実行されます。 100％安全なものはないため、常にバックアップとスタンバイノードが必要です。アップグレードで問題が発生した場合に備えて、以前のバージョンでスタンバイノードを昇格させても、システムは中断することなく動作します。
ClusterControlを使用してこの種のアップグレードを実行できます。これを行うには、ClusterControl->PostgreSQLクラスターの選択->管理->アップグレードに移動します。
選択した各ノードで、アップグレード手順は次のようになります。
-
ノードの停止
-
ノードのアップグレード
-
ノードの開始
PostgreSQLトポロジのマスターノードはアップグレードされません。マスターをアップグレードするには、最初に新しいマスターになるように別のノードを昇格させる必要があります。
メジャーアップグレードの場合、本番環境では問題が発生するリスクが高すぎるため、インプレースアップグレードはお勧めしません。これの代わりに、アップグレードを行うためのさまざまなアプローチがあります。
現在のデータベースクラスターのクローンを作成してアップグレードし、そこでアプリケーションをテストできます。終了したら、すべてが正常に行われた場合は、データベースクラスターを再作成してプロセスを繰り返し、実際のアップグレードを行うことができます。 、または、新しいバージョンで新しいクラスターを作成し、アプリケーションをテストし、準備ができたらトラフィックを切り替えることもできます。さらに多くのオプションがあります...ロードバランサーの使用は、高可用性を向上させるためにここで役立ちます。最善のアプローチは、ダウンタイムの許容範囲と目標復旧時間（RTO）によって異なります。
前述のように、アップグレードが安全であることを確認するために最初にすべてをテストする必要があるため、ClusterControlを使用してメジャーアップグレードを直接実行することはできませんが、さまざまなClusterControl機能を使用して作成できます。このタスクは簡単です。では、これらの機能のいくつかを見てみましょう。
このため、すべてを最初から作成する必要はありません。これの代わりに、ClusterControlを使用して、手動または自動でこれを行うことができます。
[バックアップ]セクションでバックアップを選択すると、[スタンドアロンホストで復元して確認する]オプションが表示され、別のノードにバックアップを復元できます。
ここで、ClusterControlでソフトウェアを新しいものにインストールするかどうかを指定できますノードを開き、ファイアウォールまたはAppArmor / SELinux（OSによって異なります）を無効にします。このためには、クラスターの一部ではない専用のホスト（またはVM）が必要です。
ノードを稼働させ続けるか、ClusterControlでデータベースをシャットダウンできます次の復元ジョブまでサービスを提供します。完了すると、バックアップリストに復元/検証済みのバックアップがチェックマークで示されます。
このタスクを手動で実行したくない場合は、スケジュールを設定できますこのプロセスでは、バックアップ機能の検証を使用して、バックアップジョブでこのジョブを定期的に繰り返します。これを行う方法については、次のセクションで説明します。
このタスクを自動化するには、ClusterControl->PostgreSQLクラスターの選択->バックアップ->バックアップの作成に移動し、スケジュールバックアップオプションを選択します。自動検証バックアップ機能は、スケジュールされたバックアップでのみ使用できます。
2番目の手順で、[バックアップの確認]オプションが有効になっていることを確認します。必要な情報を入力してください。
ジョブが終了すると、ClusterControlに確認アイコンが表示されます。バックアップセクション。手動で検証を行う場合と同じですが、復元タスクについて心配する必要がないという違いがあります。 ClusterControlは毎回自動的にバックアップを復元し、最新のデータを使用してアプリケーションをテストできます。
テスト環境を作成する別の方法は、プライマリクラスターのバックアップから新しいクラスターを作成することです。これを行うには、ClusterControl->PostgreSQLクラスターの選択->バックアップに移動します。そこで、リストから復元するバックアップを選択し、[復元]->[バックアップからクラスターを作成]を選択します。
このオプションは、選択したバックアップから新しいPostgreSQLクラスターを作成します。
OSとデータベースのクレデンシャル、および展開するための情報を追加する必要があります。新しいクラスター。このジョブが終了すると、ClusterControlUIに新しいクラスターが表示されます。
ClusterControl 1.7.4以降、クラスター間レプリケーションと呼ばれる機能があります。これにより、2つの自律クラスター間でレプリケーションを実行できます。
ClusterControlに移動->PostgreSQLクラスターを選択->クラスターアクション->スレーブクラスターの作成
スレーブクラスターは、現在のプライマリクラスターからデータをストリーミングすることによって作成されます。
SSHクレデンシャルとポート、スレーブクラスターの名前を指定する必要があります。 ClusterControlに対応するソフトウェアと構成をインストールさせたい場合。
SSHアクセス情報を設定した後、データベースのバージョンを定義する必要があります。 datadir、port、およびadminの資格情報。ストリーミングレプリケーションを使用するため、同じデータベースバージョンを使用していることを確認してください。また、資格情報はプライマリクラスターで使用されているものと同じである必要があります。
このステップでは、サーバーを新しいスレーブクラスターに追加する必要があります。このタスクでは、データベースノードのIPアドレスまたはホスト名の両方を入力できます。
ClusterControlアクティビティモニターでジョブのステータスを監視できます。タスクが完了すると、ClusterControlのメイン画面にクラスターが表示されます。
自動回復機能を有効にすると、障害が発生した場合、ClusterControlは最も高度なスタンバイノードをプライマリに昇格させ、問題を通知します。また、残りのスタンバイノードをフェイルオーバーして、新しいプライマリサーバーから複製します。
トポロジにロードバランサーがある場合、ClusterControlはそれらを再構成してトポロジの変更を適用します。
必要に応じて、手動でフェイルオーバーを実行することもできます。 ClusterControl->PostgreSQLクラスターの選択->ノード->プロモートするノードの選択->ノードアクション->スレーブのプロモートに移動します。
このようにして、アップグレード中に問題が発生した場合は、ClusterControlを使用してできるだけ早く修正できます。
ClusterControlCLIを使用した自動化
ClusterControl CLIは、s9sとも呼ばれ、ClusterControlバージョン1.4.1で導入されたコマンドラインツールであり、ClusterControlシステムを使用してデータベースクラスターを操作、制御、および管理します。 ClusterControl CLIは、クラスター自動化への扉を開き、Ansible、Puppet、Chefなどの既存のデプロイメント自動化ツールと簡単に統合できます。このツールの例をいくつか見てみましょう。
$ s9s cluster --cluster-id=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--log$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--log$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--log$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--logアップグレードは必要ですが、プロセス中の問題を回避するためにアプリケーションをテストする必要があるため、時間のかかるタスクです。自動化ツールを使用せずに、この最新の状態にアップグレードして維持する必要があるたびにテスト環境を展開するのは難しい場合があります。
ClusterControlを使用すると、ClusterControl UIまたはCLIからマイナーアップグレードを実行したり、テスト環境をデプロイしてアップグレードタスクをより簡単かつ安全にすることができます。 Ansible、Puppetなどのさまざまな自動化ツールと統合することもできます。