このページでは、コンテナのデプロイオプションを使用して AlloyDB Omni バージョン 16.3.0 について説明します。別のデプロイオプションを選択してください。

高可用性設定をテストする

ドキュメントのバージョンを選択してください。

データベースのオペレーションを継続させ、ダウンタイムを最小限に抑えるには、高可用性を持つ Patroni の設定の信頼性と品質を確保することが重要です。このページでは、障害のさまざまなシナリオ、レプリケーションの整合性、フェイルオーバーのメカニズムなど、Patroni クラスタのテストに関する包括的なガイドを紹介します。

Patroni の設定をテストする

任意の Patroni インスタンス（alloydb-patroni1、alloydb-patroni2、alloydb-patroni3）に接続し、AlloyDB Omni の Patroni フォルダに移動します。
```
cd /alloydb/
```

Patroni のログを調べます。

docker compose logs alloydbomni-patroni

エントリの最終行に Patroni ノードに関する情報が反映されているはずです。出力は次のようになります。

alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock

Linux を実行していて、プライマリ Patroni インスタンス alloydb-patroni1 にネットワーク接続できる任意のインスタンスに接続し、そのインスタンスの情報を取得します。必要に応じて、sudo apt-get install jq -y を実行して jq ツールをインストールしてください。

curl -s http://alloydb-patroni1:8008/patroni | jq .

次の例のように表示されます。

{
  "state": "running",
  "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
  "role": "master",
  "server_version": 150005,
  "xlog": {
    "location": 83886408
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "alloydbreplica",
      "application_name": "patroni2",
      "client_addr": "10.172.0.40",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "alloydbreplica",
      "application_name": "patroni3",
      "client_addr": "10.172.0.41",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "dcs_last_seen": 1715870011,
  "database_system_identifier": "7369600155531440151",
  "patroni": {
    "version": "3.3.0",
    "scope": "my-patroni-cluster",
    "name": "patroni1"
  }
}

Patroni ノードで Patroni HTTP API エンドポイントを呼び出すと、Patroni によって管理されている特定の PostgreSQL インスタンスの状態や構成に関するさまざまな詳細情報を取得できます。この情報には、クラスタのステータス情報、タイムライン、WAL 情報、ノードとクラスタが正常に稼働しているかどうかを示すヘルスチェックなどが含まれます。

HAProxy の設定をテストする

ブラウザがインストールされ、HAProxy ノードにネットワーク接続できるマシンで、アドレス http://haproxy:7000 にアクセスします。ホスト名の代わりに HAProxy インスタンスの外部 IP アドレスを使用することもできます。

画面は次のスクリーンショットのようになります。

図 1. Patroni ノードのヘルスステータスとレイテンシを示す HAProxy ステータスのページ。

HAProxy ダッシュボードでは、プライマリ Patroni ノード patroni1 と 2 つのレプリカ patroni2 と patroni3 のヘルスステータスとレイテンシを確認できます。
クエリを実行して、クラスタのレプリケーションステータスを確認できます。pgAdmin などのクライアントから HAProxy 経由でプライマリデータベースサーバーに接続し、次のクエリを実行します。
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
patroni2 と patroni3 が patroni1 からストリーミングされていることを示す、次のような画面が表示されます。

図 2. Patroni ノードのレプリケーションステータスを示す pg_stat_replication の出力。

自動フェイルオーバーをテストする

このセクションでは、3 ノード構成のクラスタで、稼働中の Patroni コンテナを停止してプライマリノードの障害をシミュレートします。プライマリノードで Patroni サービスを停止するか、ファイアウォールルールを適用してそのノードとの通信を遮断することで、障害を再現できます。

プライマリ Patroni インスタンスで、AlloyDB Omni の Patroni フォルダに移動します。
```
cd /alloydb/
```
コンテナを停止します。
```
docker compose down
```
次のような出力が表示されます。この出力により、コンテナとネットワークが正常に停止したことを確認できます。
```
[+] Running 2/2
✔ Container alloydb-patroni            Removed
✔ Network alloydbomni-patroni_default  Removed
```
HAProxy ダッシュボードを更新して、フェイルオーバーの発生状況を確認します。

図 3. プライマリノードからスタンバイノードへのフェイルオーバーを示す HAProxy ダッシュボード。

patroni3 インスタンスが新しいプライマリになり、残るレプリカは patroni2 のみになりました。以前のプライマリである patroni1 は停止し、ヘルスチェックが失敗しています。

Patroni は、モニタリング、コンセンサス、自動オーケストレーションを組み合わせてフェイルオーバーを実行・管理します。指定したタイムアウト内にプライマリノードがリースを更新しなかった場合、または障害を報告した場合、クラスタ内の他のノードはコンセンサスシステム経由でこの状態を検知します。残りのノードは、コンセンサスシステムを通じて新しいプライマリに昇格させる最も適切なレプリカを選びます。候補となるレプリカが決まると、Patroni は PostgreSQL 構成の更新や未処理の WAL レコードの再生といった必要な変更を適用して、このノードをプライマリに昇格させます。その後、新しいプライマリノードはコンセンサスシステムを自身のステータスで更新します。他のレプリカはレプリケーションソースを切り替え、必要に応じて新しいトランザクションを反映させながら、新しいプライマリに従うように再構成されます。HAProxy は新しいプライマリノードを検出し、それに応じてクライアント接続をリダイレクトして、サービスの中断を最小限に抑えます。
pgAdmin などのクライアントから HAProxy 経由でデータベースサーバーに接続し、フェイルオーバー後のクラスタのレプリケーションステータスを確認します。
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
現在 patroni2 のみがストリーミングされていることを示す、次のような画面が表示されます。

図 4. フェイルオーバー後の Patroni ノードのレプリケーションステータスを示す pg_stat_replication の出力。
このクラスタは 3 ノード構成なので、さらに 1 回の障害を許容できます。現在のプライマリノード patroni3 を停止すると、別のフェイルオーバーが発生します。

図 5. プライマリノード patroni3 からスタンバイノード patroni2 へのフェイルオーバーを示す HAProxy ダッシュボード。