フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)
一般的に、可用性グループのコンテキスト内で、可用性レプリカのプライマリ ロールとセカンダリ ロールが フェールオーバーと呼ばれるプロセスで交換されることがあります。 フェールオーバーには、自動フェールオーバー (データ損失なし)、計画的な手動フェールオーバー (データ損失なし)、および " 強制フェールオーバー" と通常呼ばれる強制手動フェールオーバー (データ損失の可能性あり) の 3 つの形式があります。 自動フェールオーバーと計画的な手動フェールオーバーでは、すべてのデータが保持されます。 可用性グループは、可用性レプリカのレベルでフェールオーバーします。 つまり、可用性グループはセカンダリ レプリカのいずれか (現在の " フェールオーバー ターゲット") にフェールオーバーされます。
Note
データベース レベルの問題 (データ ファイルの損失、データベースの削除、トランザクション ログの破損による障害が疑われる場合など) が発生しても、可用性グループのフェールオーバーは行われません。
フェールオーバーによってフェールオーバー ターゲットがプライマリ ロールを引き継ぎ、そのデータベースを復旧し、新しいプライマリ データベースとしてオンラインにします。 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに切り替わり、そのデータベースがセカンダリ データベースになります。 場合によっては、複数のエラーに対する対応として、または管理目的のために、これらのロールを何度も交代できます (または、別のフェールオーバー ターゲットに切り替えることができます)。
特定の可用性レプリカがサポートするフェールオーバーの形式は、" フェールオーバー モード " プロパティで指定されます。 可用性レプリカの有効なフェールオーバー モードは、次のようにそのレプリカの 可用性モード によって異なります。
同期コミット レプリカ: 自動と手動の 2 つの設定をサポートします。 "自動" 設定では、自動フェールオーバーと手動フェールオーバーの両方をサポートしています。 データの損失を回避するために、自動フェールオーバーおよび計画的なフェールオーバーでは、フェールオーバー ターゲットが正常な同期状態を持つセカンダリ レプリカを同期コミットします (これは、フェールオーバー ターゲット上のすべてのセカンダリ データベースが対応するプライマリ データベースと同期されることを表します)。 セカンダリ レプリカがどちらの条件も満たさない場合は、強制フェールオーバーのみがサポートされます。 ロールが RESOLVING 状態であるレプリカでも強制フェールオーバーがサポートされていることに注意してください。
非同期コミット レプリカ: 手動フェールオーバー モードのみをサポートします。 また、同期されないため、強制フェールオーバーのみをサポートします。
Note
フェールオーバー後、プライマリ データベースにアクセスする必要があるクライアント アプリケーションは、新しいプライマリ レプリカに接続する必要があります。 また、新しいセカンダリ レプリカが読み取り専用アクセスを許可するように構成されている場合は、読み取り専用クライアント アプリケーションから接続できます。 可用性グループ リスナーの詳細については、「可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)」をご覧ください。
用語と定義
自動フェールオーバー
プライマリ レプリカの喪失によって自動的に発生するフェールオーバー。 自動フェールオーバーは、現在のプライマリ レプリカと 1 つのセカンダリ レプリカのフェールオーバー モードがどちらも AUTOMATIC に設定され、セカンダリ レプリカが現在同期されている場合のみサポートされます。 プライマリ レプリカまたはセカンダリ レプリカのフェールオーバー モードが MANUAL に設定されている場合、自動フェールオーバーは実行されません。
計画的な手動フェールオーバー (データ損失なし)
計画的な手動フェールオーバーまたは " 手動フェールオーバー" は、一般的に管理目的でデータベース管理者によって開始されるフェールオーバーです。 計画的な手動フェールオーバーは、プライマリ レプリカおよびセカンダリ レプリカに同期コミット モードが構成され、セカンダリ レプリカが現在プライマリ レプリカと同期されている (SYNCHRONIZED 状態になっている) 場合にのみサポートされます。 対象のセカンダリ レプリカが同期されているときは、セカンダリ データベースでフェールオーバーの準備が整っているため、プライマリ レプリカがクラッシュした場合でも手動フェールオーバー (データ損失なし) を実行できます。 データベース管理者は手動フェールオーバーを手動で開始します。
強制フェールオーバー (データ損失の可能性あり)
プライマリ レプリカに同期されている (SYNCHRONIZED 状態の) セカンダリ レプリカがない場合、またはプライマリ レプリカが実行されていないためにセカンダリ レプリカでフェールオーバーの準備が整っていない場合に、データベース管理者が開始できるフェールオーバー。 強制フェールオーバーはデータを損失する可能性があるため、ディザスター リカバリーにのみ使用することをお勧めします。 強制フェールオーバーは、手動のみで開始できるため、強制手動フェールオーバーとも呼ばれます。 これは、非同期コミット可用性モードでサポートされているフェールオーバーの唯一の形式です。
自動フェールオーバー セット
指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。 自動フェールオーバー セットが有効になるのは、セカンダリ レプリカが現在プライマリ レプリカと同期されている場合のみです。
同期コミット フェールオーバー セット
指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。 同期コミット フェールオーバー セットは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。
全フェールオーバー セット
指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。 全フェールオーバー セットは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。
フェールオーバーの概要
次の表に、各種の可用性モードおよびフェールオーバー モードでサポートされるフェールオーバーの形式をまとめます。 それぞれの組み合わせについて、プライマリ レプリカのモードと 1 つまたは複数のセカンダリ レプリカのモードとが交差する部分から、有効な可用性モードおよびフェールオーバー モードを判定できます。
| 非同期コミット モード | 手動フェールオーバー モードを指定した同期コミット モード | 自動フェールオーバーを指定した同期コミット モード | |
|---|---|---|---|
| 自動フェールオーバー | いいえ | いいえ | はい |
| 計画的な手動フェールオーバー | いいえ | はい | はい |
| 強制フェールオーバー | はい | はい | はい***** |
* 同期されたセカンダリ レプリカで強制フェールオーバー コマンドを発行した場合、セカンダリ レプリカは手動フェールオーバーの場合と同じように動作します。
フェールオーバー中にデータベースが使用できなくなる時間の長さは、フェールオーバーの種類および原因によって異なります。
重要
フェールオーバー後もクライアント接続をサポートするには、これまでのすべてのプライマリ データベースで定義されたログインおよびジョブを新しいプライマリ データベースに手動で再作成する必要があります (ただし、包含データベースは例外)。 詳しくは、「可用性グループのデータベースのためのログインとジョブの管理 (SQL Server)」をご覧ください。
フェールオーバー セット
特定の可用性グループで可能なフェールオーバーの形式は、フェールオーバー セットの観点から理解できます。 フェールオーバー セットは、次のようにフェールオーバーの特定の形式をサポートするプライマリ レプリカとセカンダリ レプリカで構成されています。
自動フェールオーバー セット (省略可能): 指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。 自動フェールオーバー セットは、セカンダリ レプリカがプライマリ レプリカとの間で現在 SYNCHRONIZED 状態にある場合のみ有効です。
同期コミット フェールオーバー セット (省略可能): 指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。 同期コミット フェールオーバー セットは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。
全フェールオーバー セット: 指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。 全フェールオーバー セットは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。
可用性レプリカに、自動フェールオーバーが指定された同期コミット モードを構成した場合、可用性レプリカは 自動フェールオーバー セットの一部になります。 ただし、セットが有効になるかどうかは、現在のプライマリに依存します。 指定された時刻に実際に可能なフェールオーバーの形式は、現在有効なフェールオーバー セットによって決まります。
たとえば、次に示す 4 つの可用性レプリカを持つ可用性グループについて考えてみましょう。
| [レプリカ] | 可用性モードとフェールオーバー モードの設定 |
|---|---|
| A | 同期コミット モードで自動フェールオーバーを指定 |
| B | 同期コミット モードで自動フェールオーバーを指定 |
| C | 同期コミット モードで計画的な手動フェールオーバーのみを指定 |
| D | 非同期コミット モード (強制フェールオーバーのみを指定) |
各セカンダリ レプリカのフェールオーバーの動作は、現在どの可用性レプリカがプライマリ レプリカであるかによって異なります。 基本的には、特定のセカンダリ レプリカにおけるフェールオーバーの動作は、現在のプライマリ レプリカに想定される最悪のケースに対応します。 次の図は、セカンダリ レプリカのフェールオーバー動作が現在のプライマリ レプリカに応じてどのように変化するか、また、非同期コミット モード (強制フェールオーバーのみ使用) と同期コミット モード (自動フェールオーバーを使用する場合と使用しない場合があります) のどちらで構成されているかを示します。
自動フェールオーバー
自動フェールオーバーでは、プライマリ レプリカが使用できなくなった後で、対応するセカンダリ レプリカが自動的にプライマリ ロールに移行します。 セカンダリ レプリカをホストするノードに対して、プライマリ レプリカをホストする WSFC ノードがローカルである場合、自動フェールオーバーが最適です。 これには、データ同期はコンピューター間のメッセージ待機時間が短いときに最も効果的であること、およびクライアント接続をローカルに保持できるという理由があります。
自動フェールオーバーに必要な条件
自動フェールオーバーは、以下の条件が満たされた場合のみ発生します。
自動フェールオーバー セットが存在する。 このセットはプライマリ レプリカとセカンダリ レプリカ (" 自動フェールオーバー ターゲット") で構成され、プライマリ レプリカとセカンダリ レプリカは両方とも同期コミット モードで構成され、どちらも AUTOMATIC フェールオーバーに設定されています。 HYPERLINK "file:///C:\\Users\\marshow\\AppData\\Local\\Temp\\DxEditor\\DduePreview\\Default\\6fe88e12-4df1-4025-ba24-7579 635ccecf\\HTM\\html\\29e0ac5d-eb58-4801-82b9-e278f08db920" プライマリ レプリカが MANUAL フェールオーバーに設定されている場合、自動フェールオーバーは発生できません。 セカンダリ レプリカが AUTOMATIC フェールオーバーに設定されている場合でも。
詳細については、「 可用性モード (AlwaysOn 可用性グループ)」を参照してください。
自動フェールオーバー ターゲットの同期状態が正常である (これは、フェールオーバー ターゲットのすべてのセカンダリ データベースが、対応するプライマリ データベースと同期されていることを意味します)。
ヒント
AlwaysOn 可用性グループでは、自動フェールオーバー セットの両方のレプリカの状態を監視します。 いずれかのレプリカが失敗した場合、可用性グループの正常性状態が CRITICAL に設定されます。 セカンダリ レプリカが失敗した場合、自動フェールオーバー ターゲットは使用できないため、自動フェールオーバーは実行されません。 プライマリ レプリカが失敗した場合、可用性グループはセカンダリ レプリカにフェールオーバーします。 元のプライマリ レプリカがオンラインになるまで、自動フェールオーバー ターゲットは存在しません。 どちらの場合でも、可用性を確保し、連続して失敗する可能性が低くなるように、別のセカンダリ レプリカを自動フェールオーバー ターゲットとして構成することをお勧めします。
詳細については、「AlwaysOn ポリシーを使用して可用性グループの正常性を表示する (SQL Server)」、「可用性レプリカのフェールオーバー モードを変更する (SQL Server)」を参照してください。
Windows Server フェールオーバー クラスタリング (WSFC) クラスターにクォーラムがある。 詳細については、「 WSFC クォーラム モードと投票の構成 (SQL Server)」をご覧ください。
プライマリ レプリカが使用できなくなり、柔軟なフェールオーバー ポリシーにより定義されたフェールオーバー条件レベルが満たされている。 フェールオーバー条件レベルの詳細については、「可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)」を参照してください。
自動フェールオーバーの動作
自動フェールオーバーにより、次の一連の操作が開始されます。
現在のプライマリ レプリカをホストするサーバー インスタンスがまだ実行中の場合は、プライマリ データベースの状態が DISCONNECTED に変更され、すべてのクライアントが切断されます。
対象のセカンダリ レプリカの復旧キューで待機中のログ レコードがある場合、セカンダリ レプリカはそのログ レコードを適用してセカンダリ データベースのロールフォワードを終了します。
Note
特定のデータベースにログを適用するために必要な時間は、システムの処理速度、直近の作業負荷、および復旧キュー内のログの量によって異なります。
元のセカンダリ レプリカはプライマリ ロールに移行します。 そのデータベースがプライマリ データベースになります。 新しいプライマリ レプリカによって、コミットされていないすべてのトランザクションが迅速にロールバックされます (復旧の元に戻すフェーズ)。 これらのコミットされていないトランザクションがロックによって分離されるため、クライアントがデータベースを使用している間にバック グラウンドでロールバックを行うことができます。 このプロセスでは、コミット済みのトランザクションはロールバックされません。
特定のセカンダリ データベースが接続されるまでの短い間、NOT_SYNCHRONIZED としてマークされます。 ロールバックの復旧が開始される前、セカンダリ データベースは、新しいプライマリ データベースに接続し、即座に SYNCHRONIZED 状態に移行できます。 一番問題のないケースは、フェールオーバー後もセカンダリ ロールを維持する 3 番目の同期コミット レプリカです。
元のプライマリ レプリカをホストしているサーバー インスタンスが後で再起動されると、別の可用性レプリカが新たにプライマリ ロールを所有していることが認識されます。 元のプライマリ レプリカはセカンダリ ロールに移行し、そのデータベースがセカンダリ データベースになります。 新しいセカンダリ レプリカは現在のプライマリ レプリカに接続し、可能な限り早期にそのデータベースを現在のプライマリ データベースに同期します。 新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。
自動フェールオーバーを設定するには
任意の時点で、可用性レプリカが自動フェールオーバーをサポートするように構成できます。
自動フェールオーバーを設定するには
セカンダリ レプリカが、同期コミット可用性モードを使用するように構成されていることを確認します。 詳細については、「可用性レプリカの可用性モードの変更 (SQL Server)」を参照してください。
フェールオーバー モードを自動に設定します。 詳細については、「可用性レプリカのフェールオーバー モードの変更 (SQL Server)」を参照してください。
必要に応じて、可用性グループの柔軟なフェールオーバー ポリシーを変更して、自動フェールオーバーを発生させる障害の種類を指定します。 詳細については、「 自動フェールオーバー (AlwaysOn 可用性グループ) の条件を制御するようにフレキシブル フェールオーバー ポリシーを構成する」 ハイパーリンク "file:///C:\\Users\\marshow\\AppData\Local\\Temp\\DxEditor\\DduePreview\\Default\6a8d98a9-6e6a-6e6a-2013-2018-1999-6e6a- 40d1-9809-efa9013d7452\\HTM\\html\\1ed564b4-9835-4245-ae35-9ba67419a4ce" と フェールオーバー クラスター インスタンスのフェールオーバー ポリシー。
計画的な手動フェールオーバー (データ損失なし)
対象のセカンダリ レプリカがホストされているサーバー インスタンスでデータベース管理者が手動フェールオーバー コマンドを発行すると、同期済みのセカンダリ レプリカがプライマリ ロールに移行します。 手動フェールオーバーをサポートするには、セカンダリ レプリカと現在のプライマリ レプリカの両方に同期コミット モード (存在する場合) が構成されている必要があります。 可用性レプリカのすべてのセカンダリ データベースが可用性グループに参加し、その対応するプライマリ データベースに同期されている必要があります (つまり、セカンダリ レプリカを同期する必要があります)。 これにより、元のプライマリ データベースでコミットされていたトランザクションもすべて新しいプライマリ データベースに確実にコミットされます。 したがって、新しいプライマリ データベースは、古いプライマリ データベースと同じです。
次の図に、計画的なフェールオーバーの段階を示します。
フェールオーバーの前、プライマリ レプリカは
Node01のサーバー インスタンスによってホストされています。データベース管理者によって計画的なフェールオーバーが開始されます。 フェールオーバー ターゲットは、
Node02のサーバー インスタンスによってホストされている可用性レプリカです。(
Node02上の) フェールオーバー ターゲットが新しいプライマリ レプリカになります。 これは計画的なフェールオーバーであるため、フェールオーバー中に元のプライマリ レプリカはセカンダリ ロールに切り替わり、そのデータベースをセカンダリ データベースとして即座にオンラインにします。
手動フェールオーバーに必要な条件
手動フェールオーバーをサポートするには、現在のプライマリ レプリカに同期コミット モードが設定され、セカンダリ レプリカが次の条件を満たす必要があります。
同期コミット モードが構成されている。
現在、プライマリ レプリカと同期されている。
可用性グループのフェールオーバーを手動で実行するには、新しいプライマリ レプリカになるセカンダリ レプリカに接続する必要があります。
計画的な手動フェールオーバーの動作
計画的な手動フェールオーバーは、対象のセカンダリ レプリカで開始する必要があります。計画的な手動フェールオーバーによって次の処理シーケンスが開始されます。
新しいユーザー トランザクションが元のプライマリ データベースで発生しないようにするために、WSFC クラスターがプライマリ レプリカをオフラインにする要求をプライマリ レプリカに送信します。
セカンダリ データベースの復旧キューで待機中のログがある場合は、セカンダリ レプリカで、そのセカンダリ データベースのロールフォワードが終了されます。 必要な時間は、システムの処理速度、最近の作業負荷、および復旧キューのログの量によって異なります。 復旧キューの現在のサイズを調べるには、 Recovery Queue パフォーマンス カウンターを使用します。 詳細については、「 SQL Server、Database Replica」を参照してください。
Note
復旧キューのサイズを制限することでフェールオーバーの時間を調節できます。 ただし、セカンダリ レプリカの遅れを取り戻すためにプライマリ レプリカの処理速度が低下する場合があります。
セカンダリ レプリカは新しいプライマリ レプリカになり、元のプライマリ レプリカは新しいセカンダリ レプリカになります。
新しいプライマリ レプリカでは、コミットされていないトランザクションがすべてロールバックされ、そのデータベースがプライマリ データベースとしてオンラインになります。すべてのセカンダリ データベースは、新しいプライマリ データベースに接続されて再同期されるまでの短い間、NOT SYNCHRONIZED としてマークされます。 このプロセスでは、コミット済みのトランザクションはロールバックされません。
元のプライマリ レプリカはオンラインになるとセカンダリ ロールを引き継ぎ、元のプライマリ データベースがセカンダリ データベースになります。 新しいセカンダリ レプリカによって、新しいセカンダリ データベースが対応するプライマリ データベースと迅速に再同期されます。
Note
新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。
フェールオーバー後は、クライアントから現在のプライマリ データベースに再接続する必要があります。 詳細については、可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server) に関するページを参照してください。
アップグレード中の可用性の維持
可用性グループのデータベース管理者は、手動フェールオーバーを使用することにより、ハードウェアまたはソフトウェアのアップグレード時にデータベースの可用性を維持できます。 ソフトウェア アップグレードのために可用性グループを使用するには、対象のセカンダリ レプリカがホストされているサーバー インスタンスまたはコンピューター ノードでアップグレードが受信済みである必要があります。 詳細については、「 Upgrade and Update of Availability Group Servers with Minimal Downtime and Data Loss」を参照してください。
強制フェールオーバー (データ損失の可能性あり)
可用性グループの強制フェールオーバー (データ損失の可能性あり) は、セカンダリ レプリカをウォーム スタンバイ サーバーとして使用できるディザスター リカバリー方法です。フェールオーバーを強制するとデータを損失する可能性があるので、強制フェールオーバーは注意深く慎重に使用してください。 可用性データベースにサービスをすぐに復元する必要があり、データの損失を許容できる場合に限り、フェールオーバーを強制することをお勧めします。 強制フェールオーバーを実行するための前提条件と推奨事項の詳細、および強制フェールオーバーを使用して重大なエラーから復旧するサンプル シナリオについては、このトピックの「可用性グループの強制手動フェールオーバーの実行 (SQL Server)」を参照してください。
警告
強制フェールオーバーでは、WSFC クラスターにクォーラムが必要です。 クォーラム構成とクォーラムの強制の詳細については、「Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server」を参照してください。
強制フェールオーバーの動作
フェールオーバーを強制すると、ロールが SECONDARY 状態または RESOLVING 状態であるターゲット レプリカにプライマリ ロールが移行されます。 フェールオーバー ターゲットは、新しいプライマリ レプリカになり、クライアントは直ちにデータベースのコピーを利用できるようになります。 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに移行し、そのデータベースはセカンダリ データベースになります。
すべてのセカンダリ データベース (元のプライマリ データベースが使用可能になった場合は、そのプライマリ データベースを含む) が SUSPENDED 状態になります。 中断状態のセカンダリ データベースの以前のデータ同期状態に応じて、そのプライマリ データベースの損失したコミット データを復旧することが適切な場合があります。 読み取り専用アクセス用に構成されたセカンダリ レプリカで、セカンダリ データベースのクエリを実行して、損失したデータを手動で検出できます。 次に、新しいプライマリ データベースで Transact-SQL ステートメントを発行して、必要な変更を加えることができます。
強制フェールオーバーのリスク
フェールオーバーの強制によってデータが失われる可能性があることを理解しておく必要があります。 ターゲット レプリカがプライマリ レプリカと通信できなくなり、そのためにデータベースが必ずしも同期されなくなることが原因で、データが失われる可能性があります。 フェールオーバーを強制すると、新しい復旧分岐が始まります。 元のプライマリ データベースとセカンダリ データベースは別の復旧分岐に存在するので、それぞれのデータベースにはもう一方のデータベースには含まれていないデータが含まれることになります。つまり、それぞれの元のプライマリ データベースにはその送信キューから前のセカンダリ データベースに送信されなかったすべての変更 (未送信ログ) が含まれ、前のセカンダリ データベースには、フェールオーバーの強制後に行われたすべての変更が含まれます。
プライマリ レプリカで障害が発生したためにフェールオーバーが強制された場合、データが損失するかどうかは、障害発生前にセカンダリ レプリカに送信されなかったトランザクション ログがあるかどうかによって異なります。 非同期コミット モードの場合、蓄積された未送信ログがある場合は常にデータ損失の可能性があります。 同期コミット モードの場合、データが損失するのは、セカンダリ データベースが同期された状態になるまでの間だけです。
次の表に、フェールオーバーを強制するレプリカ上の特定のデータベースでのデータ損失の可能性をまとめます。
| セカンダリ レプリカの可用性モード | データベースが同期しているか | データが失われる可能性があるか |
|---|---|---|
| 同期コミット | はい | いいえ |
| 同期コミット | いいえ | はい |
| 非同期コミット | いいえ | はい |
セカンダリ データベースは 2 つの復旧分岐のみを追跡するため、複数の強制フェールオーバーを実行した場合、前の強制フェールオーバーでデータの同期を開始しなかったセカンダリ データベースは再開できない場合があります。 この場合は、再開できないセカンダリ データベースを可用性グループから削除して、適切な時点まで復元した後で再度可用性グループに参加させる必要があります。 復元は複数の復旧分岐に対しては機能しないため、複数の強制フェールオーバーを実行した後に必ずログ バックアップを実行してください。
クォーラムの強制後に強制フェールオーバーが必要な理由
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 および最終コミット時間を比較する必要があります。
プライマリ レプリカに接続します。
動的管理ビューの
last_commit_lsn(最後にコミットされたトランザクションの LSN) 列とlast_commit_time(最後のコミット時刻) 列 sys.dm_hadr_database_replica_states クエリを実行します。各プライマリ データベースとその各セカンダリ データベースに返された値を比較します。 最後にコミットした LSN の差異は、遅延の程度を示します。
1 つのデータベースまたは一連のデータベースでの遅延の程度が一定期間、指定した遅延の最大値を超えた場合に、警告を表示させることができます。 たとえば、クエリは、各プライマリ データベースで 1 分ごとに実行されるジョブによって実行できます。 プライマリ データベースとそのセカンダリ データベースの
last_commit_timeの差異が、最後にジョブが実行された後に目標復旧ポイント (RPO) (たとえば、5 分) を超えた場合、ジョブは警告を生成できます。
重要
WSFC クラスターにクォーラムが存在しない場合またはクォーラムが強制されている場合は、last_commit_lsn と last_commit_time は NULL になります。 クォーラム強制後のデータ損失を回避する方法の詳細については、「可用性グループの強制手動フェールオーバーの実行 (SQL Server)」を参照してください。
データ損失の可能性への対処
フェールオーバーの強制後は、すべてのセカンダリ データベースが中断されます。 これには、元のプライマリ データベースも含まれます (元のプライマリ レプリカは、オンラインに戻った後でセカンダリ レプリカになります)。 各セカンダリ レプリカで、中断されたデータベースをそれぞれ手動で再開する必要があります。
前のプライマリ レプリカが使用可能になると、そのデータベースは破損していないと想定されるので、データ損失の可能性に対処できます。 データ損失の可能性に対処するために使用できる方法は、元のプライマリ レプリカが新しいプライマリ レプリカに接続されたかどうかによって異なります。 元のプライマリ レプリカが新しいプライマリ インスタンスにアクセスできる場合、自動的かつ透過的に再接続されます。
元のプライマリ レプリカが再接続された場合
通常、障害発生後は、元のプライマリ レプリカは再起動するとすぐに、パートナーに再接続します。 再接続時に、元のプライマリ レプリカがセカンダリ レプリカになります。 そのデータベースはセカンダリ データベースになり、SUSPENDED 状態になります。 新しいセカンダリ データベースは、データベースを再開しない限り、ロールバックされません。
ただし、中断されたデータベースにはアクセスできないため、データベースを調査しても、指定されたデータベースを再開したときに失われるデータを評価することはできません。 そのため、セカンダリ データベースを再開するか削除するかは、次に示すようにデータの損失を許容できるかどうかによって決まります。
データの損失を許容できない場合は、データベースを可用性グループから削除して、データベースを復旧する必要があります。
データベース管理者は元のプライマリ データベースを復旧し、失われる可能性のあるデータの復旧を試みることができるようになります。 ただし、元のプライマリ データベースがオンラインになったときに、そのデータベースは現在のプライマリ データベースとは一致しません。そのため、データベース間の不一致が拡大するのを防ぎ、クライアントのフェールオーバーの問題を回避するために、データベース管理者は削除されたデータベースまたは現在のプライマリ データベースにクライアントがアクセスできないようにする必要があります。
ビジネス目標を考慮してもデータの損失を許容できる場合は、セカンダリ データベースを再開できます。
新しいセカンダリ データベースを再開すると、データベース同期の最初のステップとしてこのデータベースがロールバックされます。 障害発生時にログ レコードが送信キューで待機していた場合、対応するトランザクションはコミットされていた場合でも失われます。
元のプライマリ レプリカが再接続されなかった場合
元のプライマリ レプリカが新しいプライマリ レプリカにネットワーク経由で再接続するのを一時的に防ぐことができる場合、元のプライマリ データベースを調査して、データベースが再開されたらどのデータが失われるのかを評価できます。
データ損失が許容される場合
元のプライマリ レプリカから新しいプライマリ レプリカへの再接続を許可します。 再接続によって新しいセカンダリ データベースが中断されます。 データベースのデータの同期を開始するには、単にそれを再開します。 新しいセカンダリ レプリカがそのデータベースの元の復旧分岐を削除し、以前のセカンダリ レプリカに送信されなかったか以前のセカンダリ レプリカによって受信されなかったすべてのトランザクションが失われます。
データ損失が許容されない場合
中断されたデータベースを再開したら失われる重要なデータが元のプライマリ データベースに含まれている場合、そのデータベースを可用性グループから削除することにより元のプライマリ データベース上のデータを保持できます。 これにより、データベースが RESTORING 状態になります。 この時点で、削除されたデータベースのログの末尾をバックアップしておくことをお勧めします。 その後、復旧するデータを元のプライマリ データベースからエクスポートして、そのデータを現在のプライマリ データベースにインポートすることにより、現在のプライマリ データベース (前のセカンダリ データベース) を更新できます。 更新されたプライマリ データベースの完全バックアップを、できるだけ早く実行することをお勧めします。
その後で、RESTORE WITH NORECOVERY を使用してこのバックアップ (および 1 つ以上の後続ログ バックアップ) を復元することにより、新しいセカンダリ レプリカをホストするサーバー インスタンスで、中断されたセカンダリ データベースを削除して新しいセカンダリ データベースを作成することができます。 対応するセカンダリ データベースを再開するまで、現在のプライマリ データベースの追加のログ バックアップを遅らせることをお勧めします。
警告
プライマリ データベースでは、いずれかのセカンダリ データベースが中断している間は、トランザクション ログの切り捨てが遅延されます。 また、同期コミット セカンダリ レプリカの同期状態は、いずれかのローカル データベースが中断している間は、HEALTHY に移行できません。
Related Tasks
フェールオーバーの動作を設定するには
手動フェールオーバーを実行するには
WSFC クォーラムの構成を設定するには
関連コンテンツ
参照
AlwaysOn 可用性グループの概要 (SQL Server)
可用性モード (AlwaysOn 可用性グループ)
Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server
データベース ミラーリングまたは AlwaysOn 可用性グループではサポートされない複数データベースにまたがるトランザクション (SQL Server)
Failover Policy for Failover Cluster Instances
可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)