サポートされているフェイルオーバーと障害のシナリオ¶
フェールオーバーマネージャーは、フェールオーバーが発生する場合と発生しない場合がある障害についてクラスターを監視します。
フェールオーバーマネージャーは、非常に限定された限定的なフェールオーバーシナリオをサポートします。フェイルオーバーが発生する可能性があります。
Masterデータベースがクラッシュまたはシャットダウンした場合。
Masterデータベースをホストしているノードがクラッシュするか、到達不能になった場合。
Failover Managerは、これらの条件の正確性を検証するためにあらゆる試みを行います。マスターデータベースまたはノードに障害が発生したことをエージェントが確認できない場合、フェールオーバーマネージャーはクラスターでフェールオーバーアクションを実行しません。
フェールオーバーマネージャーは、フェールオーバーマネージャーでフェールオーバー条件を監視および検出するが、スタンバイへの自動フェールオーバーを実行しない場合に、* no * * auto - failover *モードもサポートします。このモードでは、フェールオーバー条件が満たされると、管理者に通知が送信されます。自動フェールオーバーを無効にするには、クラスタープロパティファイルを変更し、 auto.failoverを設定します パラメータをfalseに。
フェールオーバーマネージャーは、管理者の介入を必要とするが、スタンバイデータベースをマスターに昇格することに値しない状況について管理者に警告します。
マスターデータベースがダウンしています¶
Masterデータベースノードで実行されているエージェントがMasterデータベースの障害を検出すると、Failover Managerは障害を確認するプロセスを開始します。
マスターデータベースの障害の確認。¶
MasterノードのエージェントがMasterデータベースの障害を検出すると、すべてのエージェントはMasterデータベースへの直接接続を試みます。エージェントがデータベースに接続できる場合、フェールオーバーマネージャーはマスターノードの状態に関する通知を送信します。接続できるエージェントがない場合、マスターエージェントはデータベース障害を宣言し、VIPを解放します（該当する場合）。
エージェントが仮想IPアドレスまたはデータベースサーバーに到達できない場合、フェールオーバーマネージャーはフェールオーバープロセスを開始します。最新のノード上のスタンバイエージェントは、フェンシングスクリプト（該当する場合）を実行し、スタンバイデータベースをマスターデータベースに昇格させ、仮想IPアドレスをスタンバイノードに割り当てます。 auto.reconfigureがfalseに設定されていない限り、追加のスタンバイノードは新しいマスターから複製するように構成されます。該当する場合、エージェントはポストプロモーションスクリプトを実行します。
ノードをクラスターに戻す
クラスタ全体を再起動せずにこのシナリオから回復するには、次のことを行う必要があります。
元のマスターノード上のデータベースをスタンバイデータベースとして再起動します。
元のマスターノードでefm resumeコマンドを呼び出します。
ノードをマスターの役割に戻す
ノードをスタンバイとしてクラスターに戻した後、ノードをマスターの役割に簡単に戻すことができます。
クラスターに複数のスタンバイノードがある場合は、efm allow-nodeコマンドを使用して、ノードのフェールオーバー優先度を1に設定します。
efm Promote -switchoverコマンドを呼び出します ノードをマスターノードの元の役割に昇格させる。
スタンバイデータベースがダウンしている¶
スタンバイエージェントがデータベースの障害を検出した場合、エージェントは他のエージェントに通知します。他のエージェントはデータベースの状態を確認します。
スタンバイデータベースの障害の確認。¶
スタンバイデータベースを正常な状態に戻した後、efm resumeコマンドを呼び出して、スタンバイをクラスターに戻します。
マスターエージェントの終了またはノードの失敗¶
フェールオーバーマネージャーマスターエージェントがクラッシュするか、ノードに障害が発生すると、スタンバイエージェントが障害を検出し、（必要に応じて）フェールオーバーを開始します。
マスターエージェントの障害の確認。¶
マスターエージェントが去ったことをエージェントが検出した場合、すべてのエージェントはマスターデータベースに直接接続しようとします。エージェントがデータベースに接続できる場合、エージェントはマスターエージェントの障害に関する通知を送信します。接続できるエージェントがない場合、エージェントは仮想IPアドレスにpingを試行して、解放されたかどうかを判断します。
エージェントが仮想IPアドレスまたはデータベースサーバーに到達できない場合、フェールオーバーマネージャーはフェールオーバープロセスを開始します。最新ノードのスタンバイエージェントは、フェンシングスクリプト（該当する場合）を実行し、スタンバイデータベースをマスターデータベースに昇格させ、仮想IPアドレスをスタンバイノードに割り当てます。該当する場合、エージェントはポストプロモーションスクリプトを実行します。 auto.reconfigureがfalseに設定されていない限り、追加のスタンバイノードは新しいマスターから複製するように構成されます。
マスターがネットワークから分離されたためにこのシナリオが発生した場合、マスターエージェントは分離を検出して仮想IPアドレスを解放し、recovery.confファイルを作成します。フェールオーバーマネージャーは、クラスターの残りのノードで前述の手順を実行します。
クラスタ全体を再起動せずにこのシナリオから回復するには、次のことを行う必要があります。
元のマスターノードを再起動します。
元のマスターデータベースをスタンバイノードとして起動します。
元のマスターノードでサービスを開始します。
エージェントを停止しても、エージェントに障害が発生したことをクラスターに通知しないことに注意してください。
スタンバイエージェントの終了またはノードの失敗¶
スタンバイエージェントが終了するか、スタンバイノードに障害が発生すると、他のエージェントは、クラスタに接続されなくなったことを検出します。
スタンバイエージェントの障害。¶
障害が検出されると、エージェントはノードにあるデータベースへの接続を試みます。エージェントが問題があることを確認すると、フェールオーバーマネージャーは適切な通知を管理者に送信します。
マスターが1つとスタンバイが1つだけ残っている場合、マスターノードに障害が発生した場合のフェールオーバー保護はありません。マスターデータベースに障害が発生した場合、マスターエージェントとスタンバイエージェントはデータベースの障害に同意し、フェールオーバーを続行できます。
専用の監視エージェントの終了/ノードの失敗¶
次のシナリオでは、専用の証人（データベースをホストしていないノード）に障害が発生した場合に実行されるアクションについて詳しく説明します。
献身的な証人の失敗の確認¶
エージェントが監視ノードに到達できないことを検出すると、フェールオーバーマネージャーは管理者に監視の状態を通知します。
注:監視ノードに障害が発生し、クラスターに2つのノードしかない場合、スタンバイノードにはマスターが失敗したか切断されたかを知る方法がないため、フェールオーバー保護はありません。 2ノードクラスタでは、masterデータベースに障害が発生してもノードが接続されたままの場合、スタンバイがmasterデータベースの状態を確認できるため、フェールオーバーが引き続き発生します。
ノードがクラスターから分離される¶
次のシナリオでは、1つ以上のノード（クラスターの少数）がクラスターの大部分から分離された場合に実行されるアクションについて詳しく説明します。
クラスターのメンバーが分離された場合¶
1つ以上のノード（ただし、クラスターの半分未満）がクラスターの残りの部分から分離されると、残りのクラスターは、ノードに障害が発生したかのように動作します。エージェントは、マスターノードが分離されたノードに含まれているかどうかを識別しようとします。つまり、マスターはクラスターから自身をフェンスしますが、スタンバイノード（クラスターの過半数内から）はそれを置き換えるために昇格されます。 auto.reconfigureがfalseに設定されていない限り、他のスタンバイノードは新しいマスターから複製するように構成されます。
フェールオーバーマネージャーは管理者に通知し、分離されたノードは可能な場合はクラスターに再参加します。ノードがクラスターに再参加すると、フェールオーバーの優先順位が変更される場合があります。
