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