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