このドキュメントでは、AlloyDB for PostgreSQL インスタンスの高可用性（HA）構成の概要について説明します。HA の新しいインスタンスを構成する、または既存のインスタンスで HA を有効にするには、クラスタとインスタンスの設定を表示するをご覧ください。
HA 構成により、障害イベントが発生した後もオペレーションを継続できます。ゾーン インスタンスでは障害イベント中にダウンタイムが長くなる可能性がありますが、HA を使用すると、クライアント アプリケーションで引き続きデータを使用できます。
プライマリ インスタンスとセカンダリ インスタンス
高可用性で構成された AlloyDB プライマリ インスタンスには、異なるゾーンに配置されたアクティブ ノードとスタンバイ ノードが含まれます。ストレージの場合、AlloyDB はリージョン ログ永続化を使用してデータベースの write-ahead log（WAL）を保存し、AlloyDB のリージョン ストレージ サービスを使用してデータブロックを保存します。インスタンスの IP アドレスは、ロードバランサを使用してアクティブ ノードにトラフィックを転送します。
書き込みを処理するとき、AlloyDB データベースはまずアクティブ ノードのリージョン ログ永続化に WAL を書き込み、次にログを AlloyDB のリージョン ログ処理サーバーに非同期的に転送します。このサーバーは、ログを長期保存用のデータブロックに具体化します。AlloyDB は、正常に処理されたログをクリーンアップします。
次の図は、高可用性アーキテクチャを示しています。
図 1. 高可用性アーキテクチャ。
フェイルオーバー
アクティブ ノードが使用できなくなった場合、AlloyDB はプライマリ インスタンスをスタンバイ ノードに自動的にフェイルオーバーし、スタンバイ ノードが新しいアクティブ ノードになります。ロードバランサが新しいアクティブ ノードを認識し、そのノードへのトラフィックのルーティングを開始します。フェイルオーバー後、元のノードがオンラインに戻っても、新しいアクティブ ノードはアクティブのままになります。リージョン ログ永続化への同期 WAL 書き込みにより、フェイルオーバー中にデータ損失は発生しません。
次の図は、フェイルオーバー後のトラフィック フローを示しています。
図 2. フェイルオーバー後のトラフィック フロー。
フェイルオーバーは、次の一連のイベントで発生します。
- アクティブ ノードまたはゾーンで障害が発生します。AlloyDB ヘルス モニタリング システムは、アクティブ ノードが正常かどうかを定期的にチェックします。ヘルス モニタリング システムが複数のチェックに失敗すると、フェイルオーバーが開始されます。この検出には最大 30 秒かかることがあります。
- データベースがスタンバイ ノードで起動し、接続の受け入れを開始します。通常、この処理は 30 秒ほどで完了します。
- スタンバイ ノードがプライマリに昇格されます。インスタンスの静的 IP アドレスを使用して、新しいプライマリ ノードがデータの提供を開始し、再接続後にクライアント クエリが成功します。
- AlloyDB は、以前にアクティブだったゾーンにスタンバイ ノードを再作成します。このスタンバイ ノードは、今後のフェイルオーバーの準備が整います。
要件
AlloyDB がフェイルオーバーできるようにするには、次の要件を満たす構成が必要です。
- プライマリ インスタンスが通常の動作状態（停止していない、メンテナンス中でない）であること。
- スタンバイ ゾーンとスタンバイ ノードの両方が正常である必要があります。
新しいアーキテクチャ
PostgreSQL 18 を使用して新しく作成された AlloyDB インスタンスでは、スタンバイ ノード（ホット スタンバイ ノード）のリードレプリカを使用してフェイルオーバーが改善されています。
AlloyDB には、ホット スタンバイ ノードにリードレプリカが含まれています。フェイルオーバー中に、このリードレプリカは読み取り / 書き込みモードにすばやく移行できるため、ダウンタイムが短縮されます。また、リードレプリカを使用すると、ウォーム キャッシュを有効にできるため、フェイルオーバー後も一貫したクエリ パフォーマンスを維持できます。
次の図は、ホット スタンバイを含む高可用性アーキテクチャを示しています。
図 3. ホット スタンバイ。
読み取りプール
ノードが 2 つ以上の読み取りプール インスタンスは可用性の高いインスタンスです。ノードはゾーン間で均等に分散され、障害イベントに対する復元力が生まれます。ノード障害やゾーン障害などの障害イベントが発生した場合、リージョン ロードバランサは残りの正常なノードにトラフィックをルーティングし、クライアントのダウンタイムを回避します。
読み取りプールは、プライマリ インスタンスのフェイルオーバー中もオンラインのままです。フェイルオーバー中、プライマリ インスタンスからの WAL レプリケーションは一時的に一時停止し、プライマリ インスタンスが復元されると自動的に再開されます。