フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)

適用対象:SQL Server

この記事では、SQL Server Always On 可用性グループのフェールオーバーおよびフェールオーバーモードについて説明します。

概要

一般的に、可用性グループのコンテキスト内で、可用性レプリカのプライマリ ロールとセカンダリ ロールが フェールオーバーと呼ばれるプロセスで交換されることがあります。 フェールオーバーには、自動フェールオーバー (データ損失なし)、計画的な手動フェールオーバー (データ損失なし)、および " 強制フェールオーバー" と通常呼ばれる強制手動フェールオーバー (データ損失の可能性あり) の 3 つの形式があります。 自動フェールオーバーと計画的な手動フェールオーバーの両方で、すべてのデータが保持されます。 可用性グループは、可用性レプリカのレベルでフェールオーバーします。 つまり、可用性グループはセカンダリ レプリカのいずれか (現在の " フェールオーバー ターゲット") にフェールオーバーされます。

フェールオーバーによってフェールオーバー ターゲットがプライマリ ロールを引き継ぎ、そのデータベースを復旧し、新しいプライマリ データベースとしてオンラインにします。 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに切り替わり、そのデータベースがセカンダリ データベースになります。 場合によっては、複数のエラーに対する対応として、または管理目的のために、これらのロールを何度も交代できます (または、別のフェールオーバー ターゲットに切り替えることができます)。

特定の可用性レプリカがサポートするフェールオーバーの形式は、 フェールオーバー モード プロパティによって指定されます。 特定の可用性レプリカの場合、可能なフェールオーバー モードは、次のようにレプリカの 可用性モード によって異なります。

• 同期コミット レプリカ: 自動と手動の 2 つの設定をサポートします。 "自動" 設定では、自動フェールオーバーと手動フェールオーバーの両方をサポートしています。 データの損失を回避するために、自動フェールオーバーおよび計画的なフェールオーバーでは、フェールオーバー ターゲットが正常な同期状態を持つセカンダリ レプリカを同期コミットします (これは、フェールオーバー ターゲット上のすべてのセカンダリ データベースが対応するプライマリ データベースと同期されることを表します)。 セカンダリ レプリカは、これらの両方の条件を満たさない場合は常に、強制フェールオーバーのみをサポートします。 強制フェールオーバーは、RESOLVING 状態のレプリカでもサポートされます。

• 非同期コミット レプリカ: 手動フェールオーバー モードのみをサポートします。 さらに、同期されないため、強制フェールオーバーのみがサポートされます。

SQL Server 2025 の変更

SQL Server 2025 では、次の変更が導入されています。

永続的なシステムの健全性の問題に対する迅速なフェールオーバー

Always On 可用性グループ環境では、Windows フェールオーバー クラスター (WSFC) によって可用性グループとそのレプリカの 正常性が監視 されます。 プライマリ レプリカで正常性の問題が検出されると、WSFC によって一連の修正アクションがトリガーされます。 既定では、WSFC は現在のレプリカの可用性グループ リソースを再起動します。 WSFC がリソースをオンラインに戻すことができない場合、WSFC は可用性グループリソースを別のレプリカにフェールオーバーします。 この一連の修正アクションは一時的な障害に対して有効ですが、一時的でない障害のフェールオーバーの遅延につながる可能性があります。

WSFC フェールオーバーの動作は、 RestartThreshold 値によって制御されます。 既定では、Always On 可用性グループの RestartThreshold は 1 に設定されています。つまり、WSFC はフェールオーバー前に現在のノードでリソースの再起動を試みます。

SQL Server 2025 (17.x) プレビュー以降では、Always On 可用性グループの RestartThreshold を 0 に設定できます。これは、永続的な正常性の問題が検出されるとすぐに WSFC に可用性グループ リソースをフェールオーバーするように指示します。 これは、ダウンタイムを最小限に抑え、可用性グループが正常なレプリカで常に使用できるようにするシナリオに役立ちます。

明らかなトレードオフがあります。

• RestartThresholdを 1 に設定すると、可用性グループは一時的な障害に対する耐性が高まり、オンラインに戻る時間が短縮されます。 ただし、永続的な障害の場合、フェールオーバーとダウンタイムが長くなる可能性があります。
• RestartThresholdを 0 に設定すると、可用性グループは一時的な障害に対する耐性が低くなり、不必要にフェールオーバーする可能性があります。 ただし、永続的な障害の場合、フェールオーバーとダウンタイムが短くなる可能性があります。

フェールオーバー クラスター マネージャーまたは PowerShell を使用して、Always On 可用性グループ リソースの RestartThreshold を設定できます。

たとえば、RestartThresholdという名前の可用性グループのag1を 0 に設定するには、次のコマンドを使用します。

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

次のコマンドを実行して、現在の RestartThreshold 設定を確認できます。

Get-ClusterResource -Name "ag1" | Format-List *

非同期ページ要求ディスパッチの改善

可用性グループがフェールオーバーすると、各レプリカは同期先の共通の復旧ポイントを見つける必要があります。 復旧ポイントは可用性グループを安定に保ち、変更を引き続き転送できるようにします。 やり直しは 、この同期プロセスの一部です。 やり直しは、セカンダリ レプリカが共通の復旧ポイントに到達するためにトランザクションを 元に戻 す必要がある場合に発生します。 やり直しは、 FAILOVER_ALLOW_DATA_LOSSを使用した非同期レプリカへのディザスター リカバリー (DR) フェールオーバー中に最も一般的です。

DR フェールオーバーが発生した場合、セカンダリ レプリカがプライマリに移行すると、新しいプライマリに元のプライマリ (新しいセカンダリ) からのネットワーク待機時間が発生し、新しいセカンダリでのやり直しが遅くなります。

このシナリオでやり直しの取り消しを改善するために、SQL Server 2025 (17.x) プレビューでは同期メカニズムの更新プログラムが導入され、可用性グループがページ要求を非同期的かつバッチで実行できるようになりました。

次の点を考慮してください。

• 同期メカニズムの改善は、既定で有効になっています。 改善を無効にして既定の動作に戻すには、現在セカンダリまたは将来セカンダリになる可能性がある可用性グループ内のすべてのレプリカで トレース フラグ 12348 を有効にします。
• AG レプリカにネットワーク待機時間がない場合、この改善によってやり直しの取り消しが改善されない可能性があります。

データベースが障害発生後の状態の解決に切り替える

まれに、可用性グループの 1 つ以上のデータベースは、一時的なネットワーク切断やクラスター ノードの再起動の大部分など、一時的な WSFC クォーラム損失のために可用性グループが短時間オフラインになった後も 、同期されていない 状態のままになることがあります。 SQL Server 2025 (17.x) プレビューで導入された可用性グループ回復ロジックの更新により、この種類のクラスター クォーラム損失に対する内部許容度が強化され、可用性グループが再びオンラインに戻った後に可用性グループ データベースが Not Synchronizing 状態で停止するのを防ぐことができます。

用語と定義

自動フェールオーバー
プライマリ レプリカの喪失によって自動的に発生するフェールオーバー。 自動フェールオーバーは、現在のプライマリ レプリカと 1 つのセカンダリ レプリカのフェールオーバー モードがどちらも AUTOMATIC に設定され、セカンダリ レプリカが現在同期されている場合のみサポートされます。 プライマリ レプリカまたはセカンダリ レプリカのフェールオーバー モードが MANUAL の場合、自動フェールオーバーは実行できません。

計画的な手動フェールオーバー (データ損失なし)
計画的な手動フェールオーバーまたは " 手動フェールオーバー" は、一般的に管理目的でデータベース管理者によって開始されるフェールオーバーです。 計画的な手動フェールオーバーは、プライマリ レプリカとセカンダリ レプリカの両方に同期コミット モードが構成され、プライマリ レプリカとセカンダリ レプリカがどちらも現在同期されている (SYNCHRONIZED 状態になっている) 場合にのみサポートされます。 対象のセカンダリ レプリカが同期されているときは、セカンダリ データベースでフェールオーバーの準備が整っているため、プライマリ レプリカがクラッシュした場合でも手動フェールオーバー (データ損失なし) を実行できます。 データベース管理者は手動フェールオーバーを手動で開始します。

強制フェールオーバー (データ損失の可能性あり)
セカンダリ レプリカがプライマリ レプリカと SYNCHRONIZED されていないか、プライマリ レプリカが実行されておらず、セカンダリ レプリカがフェールオーバーの準備ができていない場合に、データベース管理者が開始できるフェールオーバー。 強制フェールオーバーはデータを損失する可能性があるため、ディザスター リカバリーにのみ使用することをお勧めします。 強制フェールオーバーは、手動のみで開始できるため、強制手動フェールオーバーとも呼ばれます。 これは、非同期コミット可用性モードでサポートされているフェールオーバーの唯一の形式です。

自動フェールオーバー セット

指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。 自動フェールオーバー セットは、セカンダリ レプリカがプライマリ レプリカとの間で現在 SYNCHRONIZED 状態にある場合のみ有効です。

同期コミット フェールオーバー セット

指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。 同期コミット フェールオーバー セットは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。

全フェールオーバー セット

指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。 全フェールオーバー セットは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。

フェールオーバーの概要

次の表に、各種の可用性モードおよびフェールオーバー モードでサポートされるフェールオーバーの形式をまとめます。 ペアリングごとに、有効な可用性モードとフェールオーバー モードは、プライマリ レプリカのモードと 1 つ以上のセカンダリ レプリカのモードの積集合によって決まります。

¹ 同期されたセカンダリ レプリカで強制フェールオーバー コマンドを発行した場合、セカンダリ レプリカの動作は手動フェールオーバーの場合と同じです。

フェールオーバー中にデータベースが使用できなくなる時間の長さは、フェールオーバーの種類および原因によって異なります。

フェールオーバー セット

特定の可用性グループで可能なフェールオーバーの形式は、フェールオーバー セットの観点から理解できます。 フェールオーバー セットは、次のようにフェールオーバーの特定の形式をサポートするプライマリ レプリカとセカンダリ レプリカで構成されています。

• 自動フェールオーバー セット (省略可能): 指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。 自動フェールオーバー セットは、セカンダリ レプリカがプライマリ レプリカとの間で現在 SYNCHRONIZED 状態にある場合のみ有効です。

• 同期コミット フェールオーバー セット (省略可能): 指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。 同期コミット フェールオーバー セットは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。

• 全フェールオーバー セット: 指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。 全フェールオーバー セットは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。

可用性レプリカに、自動フェールオーバーが指定された同期コミット モードを構成した場合、可用性レプリカは 自動フェールオーバー セットの一部になります。 ただし、セットが有効になるかどうかは、現在のプライマリに依存します。 指定された時刻に実際に可能なフェールオーバーの形式は、現在有効なフェールオーバー セットによって決まります。

たとえば、次に示す 4 つの可用性レプリカを持つ可用性グループについて考えてみましょう。

各セカンダリ レプリカのフェールオーバーの動作は、現在どの可用性レプリカがプライマリ レプリカであるかによって異なります。 基本的には、特定のセカンダリ レプリカにおけるフェールオーバーの動作は、現在のプライマリ レプリカに想定される最悪のケースに対応します。 次の図は、セカンダリ レプリカのフェールオーバー動作が現在のプライマリ レプリカによってどのように異なるか、および非同期コミット モード (強制フェールオーバーのみ) または同期コミット モード (自動フェールオーバーありまたは自動フェールオーバーなし) のどちらで構成されているかを示しています。

自動フェールオーバー

自動フェールオーバーでは、プライマリ レプリカが使用できなくなった後で、対応するセカンダリ レプリカが自動的にプライマリ ロールに移行します。 セカンダリ レプリカをホストするノードに対して、プライマリ レプリカをホストする WSFC ノードがローカルである場合、自動フェールオーバーが最適です。 これには、データ同期はコンピューター間のメッセージ待機時間が短いときに最も効果的であること、およびクライアント接続をローカルに保持できるという理由があります。

このセクションの内容

• 自動フェールオーバーに必要な条件

• 自動フェールオーバーの動作

• 自動フェールオーバーを有効にするには

自動フェールオーバーに必要な条件

自動フェールオーバーは、以下の条件が満たされた場合のみ発生します。

• 自動フェールオーバー セットが存在する。 このセットはプライマリ レプリカとセカンダリ レプリカ (" 自動フェールオーバー ターゲット") で構成され、プライマリ レプリカとセカンダリ レプリカは両方とも同期コミット モードで構成され、どちらも AUTOMATIC フェールオーバーに設定されています。 プライマリ レプリカが MANUAL フェールオーバーに設定されている場合、セカンダリ レプリカが AUTOMATIC フェールオーバーに設定されている場合でも、自動フェールオーバーは実行できません。

  詳細については、「可用性モード (Always On 可用性グループ)」を参照してください。

• 自動フェールオーバー ターゲットの同期状態が正常である (これは、フェールオーバー ターゲットのすべてのセカンダリ データベースが、対応するプライマリ データベースと同期されていることを意味します)。

  ヒント

  AlwaysOn 可用性グループでは、自動フェールオーバー セットの両方のレプリカの状態を監視します。 いずれかのレプリカが失敗した場合、可用性グループの正常性状態が CRITICAL に設定されます。 セカンダリ レプリカが失敗した場合、自動フェールオーバー ターゲットが使用できないため、自動フェールオーバーは実行できません。 プライマリ レプリカが失敗した場合、可用性グループはセカンダリ レプリカにフェールオーバーします。 元のプライマリ レプリカがオンラインになるまで、自動フェールオーバー ターゲットは存在しません。 どちらの場合でも、可用性を確保し、連続して失敗する可能性が低くなるように、別のセカンダリ レプリカを自動フェールオーバー ターゲットとして構成することをお勧めします。

  詳細については、「Always On ポリシーを使用した可用性グループの正常性の確認 (SQL Server)」と「可用性レプリカのフェールオーバー モードの変更 (SQL Server)」を参照してください。

• Windows Server フェールオーバー クラスタリング (WSFC) クラスターにクォーラムがある。 詳細については、「 WSFC クォーラム モードと投票の構成 (SQL Server)」をご覧ください。

• プライマリ レプリカが使用できなくなり、フレキシブル フェールオーバー ポリシーで定義されているフェールオーバー条件レベルが満たされました。 フェールオーバー条件レベルの詳細については、「可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)」を参照してください。

自動フェールオーバーの動作

自動フェールオーバーにより、次の一連の操作が開始されます。

1. 現在のプライマリ レプリカをホストするサーバー インスタンスがまだ実行中の場合は、プライマリ データベースの状態が DISCONNECTED に変更され、すべてのクライアントが切断されます。

2. 対象のセカンダリ レプリカの復旧キューで待機中のログ レコードがある場合、セカンダリ レプリカはそのログ レコードを適用してセカンダリ データベースのロールフォワードを終了します。

   注

   特定のデータベースにログを適用するために必要な時間は、システムの処理速度、直近の作業負荷、および復旧キュー内のログの量によって異なります。

3. 元のセカンダリ レプリカはプライマリ ロールに移行します。 そのデータベースがプライマリ データベースになります。 新しいプライマリ レプリカによって、コミットされていないすべてのトランザクションが迅速にロールバックされます (復旧の元に戻すフェーズ)。 これらのコミットされていないトランザクションがロックによって分離されるため、クライアントがデータベースを使用している間にバック グラウンドでロールバックを行うことができます。 このプロセスでは、コミット済みのトランザクションはロールバックされません。

   特定のセカンダリ データベースが接続されるまでは、一時的にNOT_SYNCHRONIZEDとしてマークされます。 ロールバックの復旧が開始される前、セカンダリ データベースは、新しいプライマリ データベースに接続し、即座に SYNCHRONIZED 状態に移行できます。 一番問題のないケースは、フェールオーバー後もセカンダリ ロールを維持する 3 番目の同期コミット レプリカです。

4. 元のプライマリ レプリカをホストしているサーバー インスタンスが後で再起動されると、別の可用性レプリカが新たにプライマリ ロールを所有していることが認識されます。 元のプライマリ レプリカはセカンダリ ロールに移行し、そのデータベースがセカンダリ データベースになります。 新しいセカンダリ レプリカは現在のプライマリ レプリカに接続し、可能な限り早期にそのデータベースを現在のプライマリ データベースに同期します。 新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。

自動フェールオーバーを設定するには

任意の時点で、可用性レプリカが自動フェールオーバーをサポートするように構成できます。

自動フェールオーバーを設定するには

1. セカンダリ レプリカが、同期コミット可用性モードを使用するように構成されていることを確認します。 詳細については、「可用性レプリカの可用性モードの変更 (SQL Server)」を参照してください。

2. フェールオーバー モードを自動に設定します。 詳細については、「可用性レプリカのフェールオーバー モードの変更 (SQL Server)」を参照してください。

3. 必要に応じて、可用性グループの柔軟なフェールオーバー ポリシーを変更して、自動フェールオーバーを発生させる障害の種類を指定します。 詳細については、「自動フェールオーバーの条件を制御する柔軟なフェールオーバー ポリシーの構成 (Always On 可用性グループ)」と「フェールオーバー クラスター インスタンスのフェールオーバー ポリシー」を参照してください。

計画的な手動フェールオーバー (データ損失なし)

対象のセカンダリ レプリカがホストされているサーバー インスタンスでデータベース管理者が手動フェールオーバー コマンドを発行すると、同期済みのセカンダリ レプリカがプライマリ ロールに移行します。 手動フェールオーバーをサポートするには、セカンダリ レプリカと現在のプライマリ レプリカの両方に同期コミット モード (存在する場合) が構成されている必要があります。 可用性レプリカのすべてのセカンダリ データベースが可用性グループに参加し、その対応するプライマリ データベースに同期されている必要があります (つまり、セカンダリ レプリカを同期する必要があります)。 これにより、元のプライマリ データベースでコミットされていたトランザクションもすべて新しいプライマリ データベースに確実にコミットされます。 したがって、新しいプライマリ データベースは、古いプライマリ データベースと同じです。

次の図に、計画的なフェールオーバーの段階を示します。

1. フェールオーバーの前、プライマリ レプリカは Node01のサーバー インスタンスによってホストされています。

2. データベース管理者によって計画的なフェールオーバーが開始されます。 フェールオーバー ターゲットは、 Node02のサーバー インスタンスによってホストされている可用性レプリカです。

3. ( Node02上の) フェールオーバー ターゲットが新しいプライマリ レプリカになります。 これは計画的なフェールオーバーであるため、フェールオーバー中に元のプライマリ レプリカはセカンダリ ロールに切り替わり、そのデータベースをセカンダリ データベースとして即座にオンラインにします。

計画

このセクションの内容

• 手動フェールオーバーに必要な条件

• 手動フェールオーバーの動作

• アップグレード中の可用性の維持

手動フェールオーバーに必要な条件

手動フェールオーバーをサポートするには、現在のプライマリ レプリカを同期コミット モードに設定し、セカンダリ レプリカを次のように設定する必要があります。

• 同期コミット モードが構成されている。

• 現在、プライマリ レプリカと同期されている。

可用性グループのフェールオーバーを手動で実行するには、新しいプライマリ レプリカになるセカンダリ レプリカに接続する必要があります。

計画的な手動フェールオーバーの動作

計画的な手動フェールオーバーは、対象のセカンダリ レプリカで開始する必要があります。計画的な手動フェールオーバーによって次の処理シーケンスが開始されます。

1. 新しいユーザー トランザクションが元のプライマリ データベースで発生しないようにするために、WSFC クラスターがプライマリ レプリカをオフラインにする要求をプライマリ レプリカに送信します。

2. セカンダリ データベースの復旧キューで待機中のログがある場合は、セカンダリ レプリカで、そのセカンダリ データベースのロールフォワードが終了されます。 必要な時間は、システムの処理速度、最近の作業負荷、および復旧キューのログの量によって異なります。 復旧キューの現在のサイズを調べるには、 Recovery Queue パフォーマンス カウンターを使用します。 詳細については、「 SQL Server、Database Replica」を参照してください。

   注

   復旧キューのサイズを制限することでフェールオーバーの時間を調節できます。 ただし、セカンダリ レプリカの遅れを取り戻すためにプライマリ レプリカの処理速度が低下する場合があります。

3. セカンダリ レプリカは新しいプライマリ レプリカになり、元のプライマリ レプリカは新しいセカンダリ レプリカになります。

4. 新しいプライマリ レプリカは、コミットされていないトランザクションをロールバックし、そのデータベースをプライマリ データベースとしてオンラインにします。 すべてのセカンダリ データベースは、新しいプライマリ データベースに接続して再同期するまで、一時的に NOT SYNCHRONIZED としてマークされます。 このプロセスでは、コミット済みのトランザクションはロールバックされません。

5. 元のプライマリ レプリカはオンラインになるとセカンダリ ロールを引き継ぎ、元のプライマリ データベースがセカンダリ データベースになります。 新しいセカンダリ レプリカによって、新しいセカンダリ データベースが対応するプライマリ データベースと迅速に再同期されます。

   注

   新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。

フェールオーバー後は、クライアントから現在のプライマリ データベースに再接続する必要があります。 詳細については、可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server) に関するページを参照してください。

アップグレード中の可用性の維持

可用性グループのデータベース管理者は、手動フェールオーバーを使用することにより、ハードウェアまたはソフトウェアのアップグレード時にデータベースの可用性を維持できます。 ソフトウェア アップグレードのために可用性グループを使用するには、対象のセカンダリ レプリカがホストされているサーバー インスタンスまたはコンピューター ノードでアップグレードが受信済みである必要があります。 詳細については、「 AlwaysOn 可用性グループのレプリカ インスタンスのアップグレード」を参照してください。

強制フェールオーバー (データ損失の可能性あり)

可用性グループの強制フェールオーバー (データ損失の可能性あり) は、セカンダリ レプリカをウォーム スタンバイ サーバーとして使用できるディザスター リカバリー方法です。 フェールオーバーを強制するとデータが失われる可能性があるため、慎重かつ控えめに使用する必要があります。 可用性データベースにサービスをすぐに復元する必要があり、データの損失を許容できる場合に限り、フェールオーバーを強制することをお勧めします。 強制フェールオーバーを実行するための前提条件と推奨事項の詳細、および強制フェールオーバーを使用して重大なエラーから復旧するサンプル シナリオについては、このトピックの「可用性グループの強制手動フェールオーバーの実行 (SQL Server)」を参照してください。

このセクションの内容

• 強制フェールオーバーの動作

• 強制フェールオーバーのリスク

• クォーラムの強制後に強制フェールオーバーが必要な理由

• データ損失の可能性の追跡

• データ損失の可能性への対処

強制フェールオーバーの動作

フェールオーバーを強制すると、ロールが SECONDARY 状態または RESOLVING 状態であるターゲット レプリカにプライマリ ロールが移行されます。 フェールオーバー ターゲットは、新しいプライマリ レプリカになり、クライアントは直ちにデータベースのコピーを利用できるようになります。 以前のプライマリ レプリカが使用可能になると、セカンダリ ロールに移行し、そのデータベースがセカンダリ データベースになります。

すべてのセカンダリ データベース (元のプライマリ データベースが使用可能になった場合は、そのプライマリ データベースを含む) が SUSPENDED 状態になります。 中断状態のセカンダリ データベースの以前のデータ同期状態に応じて、そのプライマリ データベースの損失したコミット データを復旧することが適切な場合があります。 読み取り専用アクセス用に構成されたセカンダリ レプリカで、セカンダリ データベースのクエリを実行して、損失したデータを手動で検出できます。 次に、新しいプライマリ データベースで Transact-SQL ステートメントを発行して、必要な変更を加えることができます。

強制フェールオーバーのリスク

フェールオーバーを強制するとデータが失われる可能性があることを理解することが不可欠です。 ターゲット レプリカがプライマリ レプリカと通信できないため、データ損失が発生する可能性があります。そのため、データベースが同期されることを保証できません。 フェールオーバーを強制すると、新しい復旧分岐が始まります。 元のプライマリ データベースとセカンダリ データベースは異なる復旧フォーク上にあるため、それぞれのデータベースには、他のデータベースに含まれていないデータが含まれるようになりました。元の各プライマリ データベースには、送信キューから以前のセカンダリ データベース (未送信ログ) にまだ送信されなかった変更が含まれています。以前のセカンダリ データベースには、フェールオーバーが強制された後に発生した変更が含まれます。

プライマリ レプリカが失敗したためにフェールオーバーが強制された場合、潜在的なデータ損失は、障害が発生する前にトランザクション ログがセカンダリ レプリカに送信されたかどうかによって異なります。 非同期コミット モードの場合、蓄積された未送信ログがある場合は常にデータ損失の可能性があります。 同期コミット モードの場合、この可能性があるのは、セカンダリ データベースが同期された状態になるまでの間だけです。

次の表に、フェールオーバーを強制するレプリカ上の特定のデータベースでのデータ損失の可能性をまとめます。

セカンダリ データベースは 2 つの復旧分岐のみを追跡するため、複数の強制フェールオーバーを実行した場合、前の強制フェールオーバーでデータの同期を開始しなかったセカンダリ データベースは再開できない場合があります。 この場合、再開できないセカンダリ データベースは、可用性グループから削除し、正しい時点に復元して、可用性グループに再参加する必要があります。 このシナリオでは、状態 103 のエラー 1408 が発生する可能性があります (エラー: 1408、重大度: 16、状態: 103)。 復元は複数の復旧分岐に対しては機能しないため、複数の強制フェールオーバーを実行した後に必ずログ バックアップを実行してください。

クォーラムの強制後に強制フェールオーバーが必要な理由

WSFC クラスターでクォーラムが強制された後 (強制クォーラム)、各可用性グループで強制フェールオーバー (データ損失の可能性あり) を実行する必要があります。 強制フェールオーバーが必要なのは、WSFC クラスター値の実際の状態が失われている可能性があるためです。 再構成された WSFC クラスターで同期されていないセカンダリ レプリカが同期されている可能性があるため、強制クォーラム後の通常のフェールオーバーを防ぐ必要があります。

たとえば、3 つのノードで可用性グループをホストする WSFC クラスターについて考えてみます。ノード A はプライマリ レプリカをホストし、ノード B とノード C はそれぞれセカンダリ レプリカをホストします。 ノード C は、ローカル セカンダリ レプリカが SYNCHRONIZED 状態の間に WSFC クラスターから切断されます。 ただし、ノード A とノード B では正常なクォーラムが保持され、可用性グループはオンラインのままになります。 ノード A では、プライマリ レプリカが引き続き更新を受け入れ、ノード B では、セカンダリ レプリカが引き続きプライマリ レプリカと同期されます。 ノード C のセカンダリ レプリカは同期されなくなり、プライマリ レプリカからしだいに遅れが生じます。 ただし、ノード C は切断されているため、レプリカは誤って SYNCHRONIZED 状態のままになります。

ノード A でクォーラムが失われた後に強制された場合は、WSFC クラスター上の可用性グループの同期の状態は正しい状態になる必要があります。つまり、ノード C のセカンダリ レプリカは UNSYNCHRONIZED 状態として示される必要があります。 ただし、ノード C でクォーラムが強制された場合、可用性グループの同期は正しくなくなります。 クラスターの同期の状態は、ノード C が切断された時点まで戻ります。つまり、ノード C のセカンダリ レプリカは誤って SYNCHRONIZED 状態として示されます。 計画された手動フェールオーバーではデータの安全性が保証されるため、クォーラムが強制された後に可用性グループをオンラインに戻すことを許可されません。

データ損失の可能性の追跡

WSFC クラスターに正常なクォーラムがある場合、データベースのデータが損失する現在の可能性を推測することができます。 特定のセカンダリ レプリカの場合、データ損失の現在の可能性は、ローカル セカンダリ データベースが対応するプライマリ データベースにどの程度遅れているかによって決まります。 遅延の程度は時間の経過と共に変化するため、非同期のセカンダリ データベースについてデータ損失の可能性を定期的に追跡することをお勧めします。 遅延を追跡するには、次のように、各プライマリ データベースとそのセカンダリ データベースの最後にコミットした LSN および最終コミット時間を比較する必要があります。

1. プライマリ レプリカに接続します。

2. sys.dm_hadr_database_replica_states 動的管理ビューの last_commit_lsn (最後にコミットされたトランザクションの LSN) 列および last_commit_time (最終コミット時間) 列に対してクエリを実行します。

3. 各プライマリ データベースとその各セカンダリ データベースに返された値を比較します。 最後にコミットした LSN の差異は、遅延の程度を示します。

4. 1 つのデータベースまたは一連のデータベースでの遅延の程度が一定期間、指定した遅延の最大値を超えた場合に、警告を表示させることができます。 たとえば、クエリは、各プライマリ データベースで 1 分ごとに実行されるジョブによって実行できます。 プライマリ データベースとそのセカンダリ データベースの last_commit_time の差異が、最後にジョブが実行された後に目標復旧ポイント (RPO) (たとえば、5 分) を超えた場合、ジョブは警告を生成できます。

データ損失の可能性への対処

フェールオーバーの強制後は、すべてのセカンダリ データベースが中断されます。 これには、以前のプライマリ レプリカがオンラインに戻り、それが現在セカンダリ レプリカであることを検出した後の、以前のプライマリ データベースが含まれます。 各セカンダリ レプリカで、中断されたデータベースをそれぞれ手動で再開する必要があります。

前のプライマリ レプリカが使用可能になると、そのデータベースは破損していないと想定されるので、データ損失の可能性に対処できます。 データ損失の可能性に対処するために使用できる方法は、元のプライマリ レプリカが新しいプライマリ レプリカに接続されたかどうかによって異なります。 元のプライマリ レプリカが新しいプライマリ インスタンスにアクセスできる場合、自動的かつ透過的に再接続されます。

元のプライマリ レプリカが再接続された場合

通常、障害発生後は、元のプライマリ レプリカは再起動するとすぐに、パートナーに再接続します。 再接続時に、元のプライマリ レプリカがセカンダリ レプリカになります。 そのデータベースはセカンダリ データベースになり、SUSPENDED 状態になります。 新しいセカンダリ データベースは、再開しない限りロールバックされません。

ただし、中断されたデータベースにはアクセスできないため、特定のデータベースを再開する場合に失われるデータを評価するためにそれらを検査することはできません。 そのため、セカンダリ データベースを再開または削除するかどうかの決定は、次のように、データ損失を受け入れるかどうかによって異なります。

• データの損失を許容できない場合は、データベースを可用性グループから削除して、データベースを復旧する必要があります。

  データベース管理者は元のプライマリ データベースを復旧し、失われる可能性のあるデータの復旧を試みることができるようになります。 ただし、以前のプライマリ データベースがオンラインになると、現在のプライマリ データベースとは異なるので、データベース管理者は、削除されたデータベースまたは現在のプライマリ データベースをクライアントにアクセスできないようにして、データベースの相違を回避し、クライアントとフェールオーバーの問題を防ぐ必要があります。

• ビジネス目標を考慮してもデータの損失を許容できる場合は、セカンダリ データベースを再開できます。

  新しいセカンダリ データベースを再開すると、データベース同期の最初のステップとしてこのデータベースがロールバックされます。 障害発生時にログ レコードが送信キューで待機していた場合、対応するトランザクションはコミットされていた場合でも失われます。

元のプライマリ レプリカが再接続されていない

元のプライマリ レプリカが新しいプライマリ レプリカにネットワーク経由で再接続するのを一時的に防ぐことができる場合、元のプライマリ データベースを調査して、データベースが再開されたらどのデータが失われるのかを評価できます。

• データ損失が許容される場合

  元のプライマリ レプリカから新しいプライマリ レプリカへの再接続を許可します。 再接続によって新しいセカンダリ データベースが中断されます。 データベースのデータの同期を開始するには、単にそれを再開します。 新しいセカンダリ レプリカがそのデータベースの元の復旧分岐を削除し、以前のセカンダリ レプリカに送信されなかったか以前のセカンダリ レプリカによって受信されなかったすべてのトランザクションが失われます。

• データ損失が許容されない場合

  中断されたデータベースを再開したら失われる重要なデータが元のプライマリ データベースに含まれている場合、そのデータベースを可用性グループから削除することにより元のプライマリ データベース上のデータを保持できます。 これにより、データベースが RESTORING 状態になります。 この時点で、削除されたデータベースのログの末尾をバックアップしておくことをお勧めします。 その後、復旧するデータを元のプライマリ データベースからエクスポートして、そのデータを現在のプライマリ データベースにインポートすることにより、現在のプライマリ データベース (前のセカンダリ データベース) を更新できます。 更新されたプライマリ データベースの完全バックアップを、できるだけ早く実行することをお勧めします。

  その後で、RESTORE WITH NORECOVERY を使用してこのバックアップ (および 1 つ以上の後続ログ バックアップ) を復元することにより、新しいセカンダリ レプリカをホストするサーバー インスタンスで、中断されたセカンダリ データベースを削除して新しいセカンダリ データベースを作成することができます。 対応するセカンダリ データベースを再開するまで、現在のプライマリ データベースの追加のログ バックアップを遅らせることをお勧めします。

関連コンテンツ

• Always On 可用性グループの概要 (SQL Server)
• 可用性モード (AlwaysOn 可用性グループ)
• Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server
• Always On 可用性グループとデータベース ミラーリングでの複数データベースにまたがるトランザクションと分散トランザクション (SQL Server)
• フェールオーバー クラスター インスタンスのフェールオーバー ポリシー
• 可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)

関連タスク

フェールオーバーの動作を構成する

• 可用性レプリカの可用性モードの変更 (SQL Server)
• 可用性レプリカのフェールオーバー モードの変更 (SQL Server)
• 自動フェールオーバーの条件を制御する柔軟なフェールオーバー ポリシーの構成 (AlwaysOn 可用性グループ)

手動フェールオーバーを実行する

• 可用性グループの計画的な手動フェールオーバーの実行 (SQL Server)
• 可用性グループの強制手動フェールオーバーの実行 (SQLServer)
• 可用性グループのフェールオーバー ウィザードの使用 (SQL Server Management Studio)
• 可用性グループのデータベースのためのログインとジョブの管理 (SQL Server)

WSFC クォーラムの設定

• クラスター クォーラムの NodeWeight の設定の構成
• クラスター クォーラムの NodeWeight 設定を表示
• クォーラムを使用せずに WSFC クラスターを強制的に起動する