このページでは、AlloyDB Omni バージョン 15.7.0 のドキュメントについて説明します。
AlloyDB Omni のドキュメントのバージョンに移動して、別のバージョンを選択します。

このページは Cloud Translation API によって翻訳されました。

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

継続的なデータベース運用を維持し、ダウンタイムを最小限に抑えるには、高可用性 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

プライマリ Patroni インスタンス alloydb-patroni1 にネットワーク接続がある Linux を実行しているインスタンスに接続し、インスタンスに関する情報を取得します。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 ダッシュボード。

フォールバックに関する考慮事項

フォールバックとは、フェイルオーバーが発生した後に以前のソースノードを復元するプロセスです。通常、高可用性データベースクラスタでは自動フォールバックはおすすめしません。これは、不完全な復元、スプリットブレインシナリオのリスク、レプリケーションラグなど、いくつかの重大な懸念があるためです。

Patroni クラスタで、停止をシミュレートした 2 つのノードを起動すると、スタンバイレプリカとしてクラスタに再参加します。

スタンバイノードとして「patroni1」と「patroni3」の復元を示す HAProxy ダッシュボード

図 6: patroni1 と patroni3 がスタンバイノードとして復元されたことを示す HAProxy ダッシュボード。

これで、patroni1 と patroni3 は現在のプライマリ patroni2 から複製されます。

フォールバック後の Patroni ノードのレプリケーションステータスを示している pg_stat_replication の出力

図 7. フォールバック後の Patroni ノードのレプリケーション状態を示す pg_stat_replication の出力。

初期プライマリに手動でフォールバックする場合は、patronictl コマンドラインインターフェースを使用します。手動フォールバックを選択すると、より信頼性が高く、一貫性があり、徹底的に検証された復元プロセスを確保し、データベースシステムの完全性と可用性を維持できます。