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

Compute Engine 上の PostgreSQL クラスタの高可用性アーキテクチャ

Last reviewed 2024-12-03 UTC

このドキュメントでは、Google Cloud での PostgreSQL デプロイメントに高可用性（HA）を提供するためのアーキテクチャについて説明します。HA は、基盤となるインフラストラクチャの障害に対するシステムの復元性を表します。このドキュメントでは、HA のアーキテクチャに応じて、HA という用語を単一のクラウドリージョン内または複数リージョン間での PostgreSQL クラスタの可用性という意味で使用しています。

このドキュメントは、システム全体の稼働時間を改善し、PostgreSQL データ層の信頼性を向上させる方法を必要としているデータベース管理者、クラウドアーキテクト、DevOps エンジニアを対象としています。このドキュメントでは、Compute Engine での PostgreSQL の実行に関連するコンセプトについて説明しますが、このドキュメントでは、Cloud SQL for PostgreSQL や AlloyDB for PostgreSQL などのマネージドデータベースの使用については説明しません。

システムやアプリケーションがリクエストまたはトランザクションの処理で永続状態を必要とする場合は、データクエリまたはミューテーションのリクエストを正常に処理するために、データパーシステンスレイヤ（データ層）を使用する必要があります。データ層でダウンタイムが発生すると、システムやアプリケーションで必要なタスクを処理できなくなります。

システムのサービスレベル目標（SLO）によっては、より高いレベルの可用性を提供するアーキテクチャが必要になることがあります。HA の実現方法はいくつかありますが、アプリケーションにすばやくアクセスできるように冗長なインフラストラクチャをプロビジョニングする方法が一般的です。

このドキュメントでは、次のトピックについて説明します。

HA データベースのコンセプトに関連する用語の定義。
HA PostgreSQL トポロジのオプション。
各アーキテクチャオプションに関するコンテキスト情報。

用語

次の用語とコンセプトは業界標準のもので、このドキュメントで扱っていない内容を理解する際にも役立ちます。

レプリケーション: 書き込みトランザクション（INSERT、UPDATE、または DELETE）とスキーマ変更（データ定義言語、DDL）のキャプチャ、ロギング、アーキテクチャ内のすべてのダウンストリームデータベースのレプリカノードへの順次適用を確実に行うプロセス。
プライマリノード: 最新状態の永続データの読み取りを行うノード。データベースへの書き込みはすべてプライマリノードに転送する必要があります。
レプリカ（セカンダリ）ノード: プライマリデータベースノードのオンラインコピー。変更は、プライマリノードからレプリカノードに同期的または非同期的に複製されます。レプリカノードからの読み取りでは、レプリケーションラグのため、データが若干遅れる可能性があるので注意してください。
レプリケーションラグ: ログシーケンス番号（LSN）、トランザクション ID、または時間から構成される測定値。レプリケーションラグは、変更オペレーションがレプリカに適用されるタイミングとプライマリノードに適用されるタイミングの差を表しています。
継続的なアーカイブ: 増分バックアップ。データベースが継続的に順次トランザクションをファイルに保存します。
write-ahead log（WAL）: write-ahead log（WAL）は、データファイルに実際に変更が加えられる前に記録されるログファイルです。WAL は、サーバーがクラッシュした場合でも書き込みデータの整合性と耐久性を確保するために使用する標準的な方法です。
WAL レコード: データベースに適用されたトランザクションのレコード。WAL レコードは、データファイルのページレベルの変更を記述する一連のレコードとしてフォーマットされ、保存されます。
ログシーケンス番号（LSN）: トランザクションにより、WAL ファイルに追加される WAL レコードが作成されます。挿入が行われる位置は、ログシーケンス番号（LSN）と呼ばれます。これは 64 ビットの整数値で、スラッシュで区切られた 2 つの 16 進数（XXXXXXXX/YYZZZZZZZ）で表現します。「Z」は、WAL ファイル内のオフセット位置を表します。
セグメントファイル: 構成されたファイルのサイズに応じて、可能な限り多くの WAL レコードを保存するファイル。セグメントファイルのファイル名は単調に増加します。デフォルトのファイルサイズは 16 MB です。
同期レプリケーション: レプリカのトランザクションログにデータが書き込まれたことをプライマリサーバーが確認してからクライアントに commit するレプリケーションの方法。ストリーミングレプリケーションを実行する場合は、PostgreSQL の synchronous_commit オプションを使用できます。これにより、プライマリサーバーとレプリカ間の整合性が確保されます。
非同期レプリケーション: レプリカでトランザクションが正常に処理されたことをプライマリサーバーが確認する前にクライアントに commit するレプリケーションの方法。非同期レプリケーションでは、同期レプリケーションよりもレイテンシが低くなります。ただし、プライマリがクラッシュし、commit されたトランザクションがレプリカに転送されない場合は、データが失われる可能性があります。非同期レプリケーションは PostgreSQL でのデフォルトのレプリケーションモードで、ファイルベースのログ配布またはストリーミングレプリケーションが使用されます。
ファイルベースのログ配布: プライマリデータベースサーバーからレプリカに WAL セグメントファイルを転送する PostgreSQL のレプリケーション方法。プライマリはアーカイブモードを継続し、各スタンバイサービスはリカバリモードを継続して WAL ファイルを読み取ります。このタイプのレプリケーションは非同期です。
ストリーミングレプリケーション: レプリカがプライマリに接続し、連続する一連の変更を継続的に受信するレプリケーション方法。この方法では、ストリーミングで更新を受信するため、ログ配布形式のレプリケーションと比べると、レプリカが常にプライマリのデータを受信し、最新の状態が維持されます。デフォルトでは、レプリケーションは非同期ですが、同期レプリケーションを構成することもできます。
物理ストリーミングレプリケーション: レプリカに変更を転送するレプリケーション方法。この方法では、ディスクブロックアドレス形式の物理データの変更とバイト単位の変更を含む WAL レコードを使用します。
論理ストリーミングレプリケーション: レプリケーション ID（主キー）に基づいて変更をキャプチャするレプリケーション方法。物理レプリケーションと比べると、データの複製方法をより詳細に制御できます。PostgreSQL では論理レプリケーションの制限があるため、論理ストリーミングレプリケーションを行うには、HA の設定で特別な構成が必要になります。このガイドでは、標準的な物理レプリケーションについて説明します。論理レプリケーションについては説明しません。
稼働時間: リソースが動作し、リクエストへのレスポンスの提供ができている時間の割合。
障害検出: インフラストラクチャ障害が発生したことを特定するプロセス。
フェイルオーバー: バックアップインフラストラクチャまたはスタンバイインフラストラクチャ（この場合は、レプリカノード）をプライマリインフラストラクチャに昇格するプロセス。フェイルオーバーが発生すると、レプリカノードがプライマリノードになります。
スイッチオーバー: 本番環境システムで手動フェイルオーバーを行うプロセス。スイッチオーバーは、システムが正常に機能しているかどうかをテストする際に使用します。また、メンテナンスのために、現在のプライマリノードをクラスタから除外する場合にも使用します。
目標復旧時間（RTO）: データ層のフェイルオーバープロセスが完了するまでの経過時間。RTO は、ビジネス上の観点から許容できる時間に応じて異なります。
目標復旧時点（RPO）: フェイルオーバーの結果、データ層を維持するために許容できるデータ損失量（実際の経過時間）。RPO は、ビジネス上の観点から許容されるデータ損失量によって異なります。
フォールバック: フェイルオーバーの原因となった条件が修正された後に以前のプライマリノードを復元するプロセス。
自己回復: オペレーターによる人的な外部アクションなしで問題を解決するシステムの能力。
ネットワークパーティション: アーキテクチャ内の 2 つのノード（たとえば、プライマリノードとレプリカノード）がネットワーク経由で相互に通信できない条件。
スプリットブレイン: 2 つのノードが同時に自身をプライマリノードであると認識している場合に発生する状態。
ノードグループ: サービスを提供するコンピューティングリソースのセット。このドキュメントでは、データパーシステンス層にあるサービスを意味します。
監視ノードまたはクォーラムノード: スプリットブレイン状態が発生した場合にノードグループの処理を決定する際に役立つ個別のコンピューティングリソース。
プライマリまたはリーダーの選択: 監視ノードを含むピアアウェアノードのグループが、どのノードをプライマリノードとすべきかを決定するプロセス。

HA アーキテクチャを検討すべき場合

HA アーキテクチャでは、単一ノードのデータベース設定よりも、データレベルのダウンタイムに対する保護が強化されます。ビジネスユースケースに最適なオプションを選択するには、ダウンタイムの許容可能性と、さまざまなアーキテクチャのトレードオフを理解する必要があります。

HA のアーキテクチャは、ワークロードとサービスの信頼性要件を満たすため、データ層の稼働率を高める場合に使用します。環境である程度のダウンタイムを許容できる場合に HA アーキテクチャを使用すると、不要なコストや複雑さが生じる可能性があります。たとえば、開発環境やテスト環境の場合、データベース層に高可用性が必要になることはまずありません。

HA の要件を検討する

以下の質問を検討して、最適な PostgreSQL HA オプションを判断してください。

どのようなレベルの可用性を実現したいのか。単一ゾーンに障害が発生したときにサービスを継続できるようにするのか、リージョン全体で障害が発生した場合でもサービスを継続するのか。マルチリージョンで使用可能な HA オプションもありますが、リージョンに限定されるものもあります。
どのサービスまたはユーザーがデータ層に依存しているのか。データパーシステンス層でダウンタイムが発生した場合にかかる費用はどのくらいか。サービスを利用するのがシステムの使用頻度が低い内部ユーザーに限定されている場合、エンドユーザー向けサービスよりも可用性の要件は低くなります。
運用予算はどのくらいか。コストは重要な検討要素です。HA を実現するために、インフラストラクチャとストレージのコストが増加する可能性があります。
プロセスをどのように自動化するのか。どのくらいの間隔でフェイルオーバーが必要になるか（RTO はどのくらいか）。HA オプションは、システムがフェイルオーバーして復旧するまでにかかる時間によって異なります。
フェイルオーバーの結果として発生するデータの消失は許容できるか（RPO はどのくらいか）。HA トポロジは分散型のため、commit のレイテンシと障害によるデータ損失のリスクがトレードオフになります。

HA の仕組み

このセクションでは、PostgreSQL HA アーキテクチャの基礎となるストリーミングレプリケーションと同期レプリケーションについて説明します。

ストリーミングレプリケーション

ストリーミングレプリケーションでは、レプリカがプライマリに接続して WAL レコードのストリームを継続的に受信します。ログ配布形式のレプリケーションと異なり、ストリーミングレプリケーションを使用すると、レプリカはプライマリとより近い状態で維持されます。PostgreSQL では、バージョン 9 から組み込みのストリーミングレプリケーションを使用できます。多くの PostgreSQL HA ソリューションでは、組み込みのストリーミングレプリケーションを使用して、複数の PostgreSQL レプリカノードがプライマリと同期されるメカニズムを提供しています。これらのオプションについては、このドキュメントの後半の PostgreSQL HA アーキテクチャのセクションで説明します。

各レプリカノードには、専用のコンピューティングリソースとストレージリソースが必要になります。レプリカノードのインフラストラクチャはプライマリから独立しています。レプリカノードをホットスタンバイとして使用して、読み取り専用のクライアントクエリを実行できます。このアプローチでは、プライマリと 1 つ以上のレプリカの間で読み取り専用クエリの負荷分散が可能です。

デフォルトでは、ストリーミングレプリケーションは非同期です。プライマリはレプリカからの確認応答を待ってから、クライアントにトランザクションの commit を確認します。非同期レプリケーションでは、トランザクションの確認後、レプリカがトランザクションを受け入れる前にプライマリで障害が発生すると、データが失われる可能性があります。レプリカが新しいプライマリに昇格すると、このようなトランザクションはなくなります。

同期ストリーミングレプリケーション

同期スタンバイにする 1 つ以上のレプリカを選択すると、ストリーミングレプリケーションを同期として構成できます。同期レプリケーションのアーキテクチャを構成すると、レプリカがトランザクションの永続性を確認するまで、プライマリはトランザクションの commit を確認しません。同期ストリーミングレプリケーションでは、トランザクションのレイテンシが大きくなるので、耐久性が高まります。

synchronous_commit 構成オプションを使用すると、トランザクションに対して次のプログレッシブレプリカの耐久性レベルを構成することもできます。

local: 同期スタンバイレプリカは commit 確認には関与しません。プライマリは、WAL レコードが書き込まれ、ローカルディスクにフラッシュされた後、トランザクション commit を承認します。プライマリでのトランザクション commit には、スタンバイレプリカは関与しません。プライマリで障害が発生すると、トランザクションが失われる可能性があります。
on（デフォルト）: 同期スタンバイレプリカが commit されたトランザクションを WAL に書き込んでから、プライマリに確認を送信します。on 構成を使用すると、プライマリレプリカとすべての同期スタンバイレプリカで同時にストレージ障害が発生した場合にのみ、トランザクションが失われる可能性があります。レプリカが確認応答を送信するのは WAL レコードの書き込み後であるため、レプリカにクエリを送信するクライアントは、WAL レコードがレプリカデータベースに適用されるまで変更を確認できません。
remote_write: 同期スタンバイレプリカは、OS レベルで WAL レコードの受信を認識しますが、WAL レコードがディスクに書き込まれたかどうかは保証しません。remote_write では WAL の書き込みを保証できないため、レコードを書き込む前にプライマリとセカンダリの両方で障害が発生すると、トランザクションが失われる可能性があります。remote_write の耐久性は on オプションよりも低くなります。
remote_apply: 同期スタンバイレプリカは、クライアントにトランザクションの commit を確認する前に、トランザクションの受信とデータベースへの正常な適応を確認します。remote_apply 構成を使用すると、トランザクションがレプリカに確実に保持され、クライアントクエリの結果にトランザクションの結果がすぐに反映されます。on や remote_write と比べると、remote_apply は耐久性と整合性が高くなります。

synchronous_commit 構成オプションは、同期レプリケーションプロセスに参加するスタンバイサーバーのリストを指定する synchronous_standby_names 構成オプションで機能します。同期スタンバイ名が指定されていない場合、トランザクション commit はレプリケーションを待機しません。

PostgreSQL HA アーキテクチャ

最も基本的なレベルでは、データ層の HA は次の要素から構成されます。

プライマリノードの障害発生を認識するメカニズム。
レプリカノードをプライマリノードに昇格するフェイルオーバーを実行するプロセス。
アプリケーションのリクエストが新しいプライマリノードに到達するようにクエリルーティングを変更するプロセス。
フェイルオーバー前のプライマリノードとレプリカノードを元の容量で使用して、元のアーキテクチャにフォールバックする方法（必要な場合）。

以降のセクションでは、次の HA アーキテクチャの概要について説明します。

Patroni テンプレート
pg_auto_failover 拡張機能とサービス
ステートフル MIG とリージョン永続ディスク

HA ソリューションは、インフラストラクチャまたはゾーンの停止が発生した場合にダウンタイムを最小限に抑えます。オプションを選択する際は、ビジネスニーズに応じて commit レイテンシと耐久性を考慮し、バランスの良いオプションを選択します。

HA アーキテクチャでは、今後のフェイルオーバーまたはフォールバックに備えるために新しいスタンバイ環境の準備に必要になる時間と手間が重要な要素となります。このような準備を行わないと、システムが 1 回の障害にしか耐えられず、サービスが SLA に違反することになります。本番環境のインフラストラクチャでは、手動フェイルオーバーまたはスイッチオーバーが可能な HA アーキテクチャを選択することをおすすめします。

Patroni テンプレートを使用した HA

Patroni は、PostgreSQL HA アーキテクチャを構成、デプロイ、運用するためのツールを提供するオープンソース（MIT ライセンス）のソフトウェアテンプレートです。これは完成度の高いテンプレートで、メンテナンスが積極的に行われています。Patroni には共有クラスタ状態のものと、分散構成ストア（DCS）に保持されているアーキテクチャ構成があります。DCS を実装するためのオプションとしては、etcd、Consul、Apache ZooKeeper、Kubernetes があります。次の図は、Patroni クラスタの主なコンポーネントを示しています。

Patroni クラスタと PostgreSQL ノード、DCS、Patroni エージェントの関係。

図 1: Patroni クラスタの主なコンポーネントの図。

図 1 では、PostgreSQL ノードの前にロードバランサが配置され、DCS と Patroni エージェントが PostgreSQL ノードで稼働しています。

Patroni は、各 PostgreSQL ノードでエージェントプロセスを実行します。エージェントプロセスは、PostgreSQL プロセスとデータノードの構成を管理します。Patroni エージェントは、DCS を介して他のノードとの調整を行います。Patroni エージェントプロセスは、各ノードの PostgreSQL サービスの正常性と構成を判断するための REST API も公開しています。

クラスタメンバーの役割を明確にするため、プライマリノードは DCS のリーダーキーを定期的に更新します。リーダーキーには有効期間（TTL）が設定されています。更新されずに TTL が経過すると、リーダーキーは DCS から強制排除され、リーダーの選択が開始し、候補者プールから新しいプライマリが選択されます。

次の図は、ノード A がリーダーロックを正常に更新する正常なクラスタを示しています。

リーダー候補がウォッチしている間に、正常なクラスタリーダーがリーダーロックを更新しています。

図 2: 正常なクラスタの図。

図 2 は正常なノードを示しています。ノード B とノード C がウォッチしている間に、ノード A がリーダーキーを正常に更新しています。

障害検出

Patroni エージェントは、DCS のキーを更新することで、正常な状態を継続的に伝達します。同時に、エージェントは PostgreSQL の健全性を検証します。エージェントが問題を検出すると、ノードをシャットダウンして自動的にノードを隔離するか、ノードのレプリカを降格します。次の図に示すように、障害が発生したノードがプライマリの場合、DCS のリーダーキーが期限切れになり、新しいリーダーの選択が行われます。

クラスタで障害が発生すると、既存のリーダーキーの期限が切れた後、新しいリーダーが選択されます。

図 3: 障害が発生したクラスタの図。

図 3 は、障害が発生したクラスタを示しています。プライマリノードが DCS のリーダーキーを最近更新しておらず、リーダー以外のレプリカにリーダーキーの期限切れが通知されています。

Linux ホストの場合、Patroni もプライマリノードで OS レベルのウォッチドッグを実行します。このウォッチドッグは、Patroni エージェントプロセスからの keep-alive メッセージをリッスンします。プロセスが応答しなくなり、keep-alive が送信されない場合、ウォッチドッグがホストを再起動します。ウォッチドックは、PostgreSQL ノードがプライマリとして機能し続けるスプリットブレイン状態の回避に役立ちますが、エージェント障害で DCS のリーダーキーが期限切れになるため、別のプライマリ（リーダー）が選択されています。

フェイルオーバープロセス

リーダーロックが DCS で期限切れになると、レプリカノードがリーダーの選択を開始します。レプリカでリーダーロックがないことが検出されると、他のレプリカと比較してレプリカの位置が確認されます。次の図に示すように、各レプリカは REST API を使用して他のレプリカノードの WAL ログの位置を取得します。

Patroni フェイルオーバープロセス中にレプリカは WAL ログで自身の位置を確認します。

図 4: Patroni フェイルオーバープロセスの図。

図 4 は、WAL ログ位置のクエリとアクティブなレプリカノードからの結果を示しています。ノード A が使用不能になり、正常なノード B と C が互いに同じ WAL 位置を返しています。

最新のノード（同じ位置にある場合は複数のノード）が同時に DCS のリーダーロックを取得しようとします。ただし、DCS にリーダーキーを作成できるのは 1 つのノードのみです。次の図に示すように、リーダーキーが正常に作成された最初のノードがリーダーレースの勝者になります。また、構成ファイルで failover_priority タグを設定することで、優先されるフェイルオーバー候補を指定することもできます。

ノードが DCS にリーダーキーを作成し、新しいプライマリになります。

図 5: リーダーレースの図。

図 5 はリーダースコアを表しています。2 つのリーダー候補がリーダーロックを獲得しようとしていますが、2 つのノードのうちノード C のみがリーダーキーの設定に成功し、レースの勝者となっています。

リーダーに選択されると、レプリカは自身を新しいプライマリに昇格させます。レプリカが自身の昇格を開始すると、新しいプライマリが DCS のリーダーキーを更新してリーダーロックを保持し、他のノードはレプリカとして機能します。

Patroni には、スイッチオーバーを実行してノードのフェイルオーバーをテストできる patronictl コントロールツールも用意されています。このツールは、本番環境における HA 設定をテストするのに役立ちます。

クエリルーティング

各ノードで実行される Patroni エージェントプロセスは、現在のノードの役割（プライマリかレプリカ）を示す REST API エンドポイントを公開します。

REST エンドポイント	プライマリの場合の HTTP リターンコード	レプリカの場合の HTTP リターンコード
`/primary`	`200`	`503`
`/replica`	`503`	`200`

特定のノードの役割が変更されると関連するヘルスチェックのレスポンスが変わるため、ロードバランサのヘルスチェックは、これらのエンドポイントを使用してプライマリノードとレプリカノードのトラフィックルーティングを通知します。Patroni プロジェクトは、HAProxy などのロードバランサのテンプレート構成を提供しています。内部パススルーネットワークロードバランサは、これらの同じヘルスチェックを使用して同様の機能を提供できます。

フォールバックプロセス

ノードに障害が発生すると、クラスタは異常な状態のままになります。Patroni のフォールバックプロセスは、フェイルオーバー後に HA クラスタを正常な状態に戻すのに役立ちます。フォールバックプロセスは、影響を受けたノードをクラスタレプリカとして自動的に初期化することで、クラスタの元の状態を復元します。

たとえば、オペレーティングシステムや基盤となるインフラストラクチャに問題があると、ノードが再起動することがあります。ノードがプライマリで、再起動にリーダーキーの TTL よりも時間がかかる場合、リーダーの選択がトリガーされ、新しいノードが選択されてプライマリに昇格されます。最新でないプライマリの Patroni プロセスが開始すると、リーダーロックがないことが検出され、自動的にレプリカに降格され、クラスタに参加します。

ゾーンの障害など、回復不能なノード障害が発生した場合は、新しいノードを起動する必要があります。データベースオペレーターは、新しいノードを手動で開始することも、最小ノード数が設定されたステートフルマネージドインスタンスグループ（MIG）を使用してプロセスを自動化することもできます。新しいノードが作成されると、Patroni はそのノードを既存のクラスタの一部として検出し、自動的にレプリカとして初期化します。

pg_auto_failover 拡張機能とサービスを使用する HA

pg_auto_failover は、積極的に開発されているオープンソース（PostgreSQL ライセンス）の PostgreSQL 拡張機能です。pg_auto_failover は、既存の PostgreSQL 機能を拡張して HA アーキテクチャを構成します。pg_auto_failover には PostgreSQL 以外の依存関係はありません。

HA アーキテクチャで pg_auto_failover 拡張機能を使用するには、少なくとも 3 つのノードが必要です。各ノードでは、拡張機能を有効にして PostgreSQL を実行する必要があります。どのノードで障害が発生しても、データベースグループの稼働時間に影響を与えることはありません。pg_auto_failover によって管理されるノードのコレクションはフォーメーションと呼ばれます。次の図に、pg_auto_failover のアーキテクチャを示します。

ノードのフォーメーションを含む pg_auto_failover アーキテクチャ。

図 6: pg_auto_failover アーキテクチャの図。

図 6 は、2 つの主要コンポーネント（Monitor サービスと Keeper エージェント）で構成される pg_auto_failover アーキテクチャを示しています。Keeper と Monitor はどちらも pg_auto_failover 拡張機能に含まれています。

サービスのモニタリング

pg_auto_failover Monitor サービスは PostgreSQL 拡張機能として実装されます。このサービスは、Monitor ノードを作成すると、pg_auto_failover 拡張機能を有効にして PostgreSQL インスタンスを開始します。Monitor は、フォーメーションのグローバル状態を維持して、メンバー PostgreSQL データノードからヘルスチェックステータスを取得し、有限状態機械（FSM）で設定されたルールを使用してグループをオーケストレートします。Monitor は、状態遷移に対する FSM ルールに従い、昇格、降格、構成の変更などのアクションをグループノードに指示します。

Keeper エージェント

この拡張機能は、各 pg_auto_failover データノードで Keeper エージェントプロセスを開始します。この Keeper プロセスは、PostgreSQL サービスを監視して管理します。Keeper は、ステータスの更新を Monitor ノードに送信し、そのレスポンスで Monitor から受信したアクションを実行します。

デフォルトでは、pg_auto_failover は、すべてのグループのセカンダリデータノードを同期レプリカとして設定します。commit に必要な同期レプリカの数は、Monitor に設定した number_sync_standby 構成に応じて変わります。

障害検出

プライマリデータノードとセカンダリデータノードの Keeper エージェントは、定期的に Monitor ノードに接続して現在の状態を報告し、実行が必要なアクションがあるかどうかを確認します。また、Monitor ノードはデータノードに接続し、ヘルスチェックを実行します。PostgreSQL プロトコル（libpq）API 呼び出しを実行し、pg_isready() PostgreSQL クライアントアプリケーションのように動作します。一定の時間（デフォルトでは 30 秒）が経過しても、これらの操作が正常に完了しなかった場合、Monitor ノードはデータノードに障害が発生したと判断します。PostgreSQL の構成設定を変更して、モニタリングのタイミングと再試行の回数をカスタマイズできます。詳しくは、フェイルオーバーとフォールトトレラントをご覧ください。

単一ノード障害が発生した場合、次のいずれかの状態になります。

異常なデータノードがプライマリの場合、Monitor はフェイルオーバーを開始します。
異常なデータノードがセカンダリの場合、Monitor は異常なノードの同期レプリケーションを無効にします。
障害が発生したノードが Monitor ノードの場合、自動フェイルオーバーは実行されません。この単一障害点を回避するには、適切なモニタリングと障害復旧を実施する必要があります。

次の図に、上記以外の障害シナリオとその場合のフォーメーションの状態を示します。

プライマリ障害、セカンダリ障害、Monitor ノードの障害に対する pg_auto_failover のシナリオ。

図 7: pg_auto_failover の障害シナリオの図。