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