Supported failover and failure scenarios ======================================== フェールオーバーマネージャーは、フェールオーバーの原因となる可能性のある障害がクラスターを監視します。 フェールオーバーマネージャーは、特定の限定的なフェールオーバーシナリオをサポートします。フェイルオーバーが発生する場合があります。 - プライマリデータベースがクラッシュするか、シャットダウンされた場合。 - プライマリデータベースをホストするノードがクラッシュするか、到達不能になった場合。 フェールオーバーマネージャーは、これらの条件の精度を確認するためにあらゆる試みを行います。プライマリデータベースまたはノードに障害が発生したことをエージェントが確認できない場合、フェールオーバーマネージャーはクラスターでフェールオーバーアクションを実行しません。 フェールオーバーマネージャーは、フェールオーバーマネージャーがフェールオーバー条件を監視および検出するが、スタンバイへの自動フェールオーバーを実行しない場合に、 *no auto- フェールオーバー* モードもサポートします。このモードでは、フェールオーバー条件が満たされると、管理者に通知が送信されます。自動フェイルオーバーを無効にするには、クラスタープロパティファイルを変更し、 :ref:`auto.failover ` パラメーターを\ ``false`` に設定します。 フェールオーバーマネージャーは、管理者の介入を必要とするが、スタンバイデータベースをプライマリに昇格することに値しない状況について、管理者に警告します。 プライマリデータベースがダウンしています ---------------------------------------- プライマリデータベースノードで実行されているエージェントがプライマリデータベースの障害を検出すると、フェールオーバーマネージャーは障害を確認するプロセスを開始します。 .. figure:: /images/supported_scenarios_master_db_down.png :width: 70% :alt: Confirming the failure of the primary database. Confirming the failure of the primary database. プライマリノードのエージェントがプライマリデータベースに障害が発生したことを検出すると、すべてのエージェントがプライマリデータベースに直接接続しようとします。エージェントがデータベースに接続できる場合、フェールオーバーマネージャーはプライマリノードの状態に関する通知を送信します。接続できるエージェントがない場合、プライマリエージェントはデータベース障害を宣言し、VIPを解放します該当する場合。 エージェントが仮想IPアドレスまたはデータベースサーバーに到達できない場合、フェールオーバーマネージャーはフェールオーバープロセスを開始します。最新のノードのスタンバイエージェントは、フェンシングスクリプト該当する場合を実行し、スタンバイデータベースをプライマリデータベースに昇格させ、仮想IPアドレスをスタンバイノードに割り当てます。 ``auto.reconfigure`` が\ ``false`` に設定されていない限り、追加のスタンバイノードは新しいプライマリから複製するように構成されます。必要に応じて、エージェントはプロモーション後のスクリプトを実行します。 ノードをクラスターに戻す ------------------------ クラスター全体を再起動せずにこのシナリオから復旧するには 1. 元のプライマリノードでデータベースをスタンバイデータベースとして再起動します。 2. 元のプライマリノードで\ ``efm resume`` コマンドを呼び出します。 ノードをプライマリのロールに戻す -------------------------------- ノードをスタンバイとしてクラスターに戻した後、ノードをプライマリの役割に簡単に戻すことができます。 1. クラスターに複数のスタンバイノードがある場合、 ``efm set-priority`` コマンドを使用してノードのフェールオーバー優先度を1に設定します。 2. :ref:`efm promote ` コマンドを呼び出して、ノードをプライマリノードの元の役割に昇格させます。 !!!note デフォルトでは、フェールオーバーマネージャーは、障害が発生したプライマリデータベースをスタンバイになるように再構築しません。再構築する前に、プライマリに障害が発生した理由を特定し、新しいプライマリですべてのデータを利用できることを確認することが重要です。サーバーをスタンバイとして復元する準備ができたら、古いデータディレクトリを削除し、サーバーを復元できます。詳細については、 `setting up a standby server `_ のPostgreSQLドキュメントを参照してください。場合によっては、 `pg_rewind `_ を使用してサーバーを復元することもできます。 バージョン5.1以降、フェールオーバーマネージャーが障害が発生したプライマリデータベースを再構築しようとする機能を有効にできます。この機能は、障害が発生したノードをクラスターに戻す必要があり、障害の原因が既知および予測可能なユースケースを対象としているため、注意して使用します。 EFMが障害が発生したプライマリを再構築できない状況が発生する場合があり、引き続き手動介入が必要です。詳細については、 :ref:`the auto.rewind cluster property ` を参照してください。 .. :: ## スタンバイデータベースがダウンしています スタンバイエージェントがデータベースの障害を検出すると、エージェントは他のエージェントに通知します。他のエージェントは、データベースの状態を確認します。 .. figure:: /images/supported_scenarios_standby_db_down.png :width: 40% :alt: Confirming the failure of a standby database. Confirming the failure of a standby database. スタンバイデータベースを正常な状態に戻した後、 ``efm resume`` コマンドを呼び出して、スタンバイをクラスターに戻します。 プライマリエージェントが終了するか、ノードに障害が発生 ------------------------------------------------------ フェールオーバーマネージャープライマリエージェントがクラッシュするか、ノードに障害が発生すると、スタンバイエージェントが障害を検出し、必要に応じてフェールオーバーを開始します。 .. figure:: /images/supported_scenarios_master_agent_exits.png :width: 70% :alt: Confirming the failure of the primary agent Confirming the failure of the primary agent プライマリエージェントが去ったことをエージェントが検出した場合、すべてのエージェントはプライマリデータベースに直接接続しようとします。データベースに接続できるエージェントがある場合、エージェントはプライマリエージェントの障害に関する通知を送信します。接続できるエージェントがない場合、エージェントは仮想IPアドレス該当する場合にpingを試行して、解放されたかどうかを判断します。 エージェントが仮想IPアドレスまたはデータベースサーバーに到達できない場合、フェールオーバーマネージャーはフェールオーバープロセスを開始します。最新のノードのスタンバイエージェントは、フェンシングスクリプト該当する場合を実行し、スタンバイデータベースをプライマリデータベースに昇格させ、仮想IPアドレスをスタンバイノードに割り当てます。必要に応じて、エージェントはプロモーション後のスクリプトを実行します。 ``auto.reconfigure`` が\ ``false`` に設定されていない限り、追加のスタンバイノードは新しいプライマリから複製するように構成されます。 プライマリがネットワークから分離されたためにこのシナリオが発生した場合、プライマリエージェントは分離を検出し、仮想IPアドレスを解放し、\ ``recovery.conf`` ファイルを作成します。フェールオーバーマネージャーは、クラスターの残りのノードでこれらと同じ手順を実行します。クラスタ全体を再起動せずにこのシナリオから回復するには、次のことを行う必要があります。 クラスター全体を再起動せずにこのシナリオから復旧するには 1. 元のプライマリノードを再起動します。 2. 元のプライマリデータベースをスタンバイノードとして起動します。 3. 元のプライマリノードでサービスを開始します。 .. Note::: エージェントを停止しても、エージェントに障害が発生したことはクラスターに通知されません。 プライマリフェールオーバーマネージャープロセスに障害が発生した場合、エージェントが再起動するまでフェールオーバー保護はありません。この場合を回避するには、systemdを介してプライマリノードを設定して、プライマリエージェントの終了時にフェールオーバーを発生させることができます。詳細については、 :ref:`Configuring for Eager Failover ` を参照してください。 スタンバイエージェントが終了するか、ノードに障害が発生 ------------------------------------------------------ スタンバイエージェントが終了するか、スタンバイノードに障害が発生すると、他のエージェントは、クラスタに接続されなくなったことを検出します。 .. figure:: /images/supported_scenarios_standby_agent_exits.png :width: 40% :alt: Failure of standby agent Failure of standby agent 障害が検出されると、エージェントはノードにあるデータベースへの接続を試みます。エージェントが問題があることを確認すると、フェールオーバーマネージャーは管理者に適切な通知を送信します。 1つのプライマリと1つのスタンバイのみが残っている場合、プライマリノードに障害が発生した場合のフェールオーバー保護はありません。プライマリデータベースに障害が発生した場合、プライマリエージェントとスタンバイエージェントは、データベースに障害が発生したことに同意し、フェールオーバーを続行できます。 専用の監視エージェントが終了/ノードに障害が発生 ----------------------------------------------- このシナリオでは、専用の監視データベースをホストしていないノードに障害が発生した場合に実行されるアクションについて詳しく説明します。 .. figure:: /images/supported_scenarios_witness_agent_exits.png :width: 40% :alt: Confirming the failure of a dedicated witness Confirming the failure of a dedicated witness 監視ノードに到達できないことをエージェントが検出すると、フェールオーバーマネージャーは監視の状態を管理者に通知します。 .. Note:: 監視に障害が発生し、クラスターに2つのノードのみがある場合、フェールオーバー保護はありません。スタンバイノードは、プライマリに障害が発生したか、切断されたかを知ることができません。 2ノードクラスターでは、プライマリデータベースに障害が発生してもノードがまだ接続されている場合、フェールオーバーは引き続き発生します。スタンバイは、プライマリデータベースの状態を確認できます。 ノードがクラスターから分離される -------------------------------- このシナリオでは、1つ以上のノードクラスターのマイノリティがクラスターの大部分から分離された場合に実行されるアクションについて詳しく説明します。 .. figure:: /images/supported_scenarios_node_becomes_isolated.png :width: 70% :alt: If members of the cluster become isolated If members of the cluster become isolated 1つ以上のノードただし、クラスターの半分未満がクラスターの残りの部分から分離されると、残りのクラスターは、ノードに障害が発生したかのように動作します。エージェントは、プライマリノードが分離されたノードの中にあるかどうかを識別しようとします。その場合、プライマリはクラスターから自分自身をフェンスオフしますが、クラスターマジョリティ内のスタンバイノードがそれを置き換えるように昇格します。 ``auto.reconfigure`` が\ ``false`` に設定されていない限り、他のスタンバイノードは新しいプライマリから複製するように構成されます。 フェールオーバーマネージャーは管理者に通知し、分離されたノードは可能な場合はクラスターに再参加します。ノードがクラスターに再参加すると、フェールオーバーの優先順位が変更される場合があります。