フェールオーバーマネージャーの概要¶
EDBPostgres|variable_prod_name|（EFM）クラスターは、ネットワーク上の次のホストにあるFailoverManagerプロセスで構成されています。
マスターノード-マスターノードは、データベースクライアントにサービスを提供するプライマリデータベースサーバーです。
1つ以上のスタンバイノード-スタンバイノードは、マスターノードに関連付けられたストリーミングレプリケーションサーバーです。
ウィットネスノード-ウィットネスノードは、フェイルオーバーシナリオでのマスターまたはスタンバイのアサーションを確認します。クラスターに3つ以上のノードが含まれている場合、クラスターには専用の監視ノードは必要ありません。データベースホストである3番目のクラスターメンバーがない場合は、専用の監視ノードを追加できます。クラスタには複数の監視ノードが含まれる場合があります。
伝統的に、*クラスター*は複数のデータベースを管理するPostgresの単一のインスタンスです。このドキュメントでは、クラスターという用語は|variable_prod_name|を指します。集まる。|variable_prod_name|クラスターは、マスターエージェント、1つ以上のスタンバイエージェント、およびクラウドまたは従来のネットワーク上のサーバーに常駐し、JGroupsツールキットを使用して通信するオプションの監視エージェントで構成されます。
仮想IPアドレスを使用するEFMシナリオ。¶
非監視エージェントが起動すると、ローカルデータベースに接続し、データベースの状態を確認します。
エージェントがデータベースに到達できない場合は、アイドルモードで起動します。
データベースが回復中であることが判明した場合、エージェントはスタンバイの役割を担います。
データベースがリカバリ中でない場合、エージェントはマスターの役割を引き受けます。
フェイルオーバーが発生した場合、|variable_prod_name|昇格したスタンバイがクラスター内で最新のスタンバイであることを確認しようとします。スタンバイノードがマスターノードと同期していない場合、データが失われる可能性があることに注意してください。
`JGroups<http://www.jgroups.org/>`_は|variable_prod_name|を可能にするテクノロジーを提供しますメンバーノードが相互に通信し、ノードの障害を検出できるクラスターを作成します。
上の図は、|variable_prod_name|を示しています。仮想IPアドレスを使用するクラスター。 :doc:`仮想IPアドレスの代わりにロードバランサーを使用できます<using_vip_addresses>`独自の :doc:`scriptを提供する場合<cluster_properties>`障害発生時にロードバランサーを再構成します。