WSFC の強制クォーラムによる災害復旧 (SQL Server)
クォーラム障害は、通常、システム障害、永続的な通信障害、または WSFC クラスター内の複数のノードにおける不適切な構成が原因で発生します。 クォーラム障害からの復旧には、手動による介入が必要になります。
開始前の準備: 前提条件、セキュリティ
WSFC の強制クォーラムの手順による災害復旧 クォーラム障害から復旧するには
関連タスク
関連コンテンツ
作業を開始する準備
前提条件
強制クォーラムの手順では、クォーラム障害の発生前に、正常なクォーラムが存在していたことを前提としています。
.gif "注記") 注意 |
|---|
ユーザーは、Windows Server フェールオーバー クラスタリング、WSFC クォーラム モデル、SQL Server、および環境に固有の配置構成の概念および操作に関する十分な知識を持っている必要があります。 詳細については、「Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server」および「WSFC クォーラム モードと投票の構成 (SQL Server)」を参照してください。 |
セキュリティ
ユーザーは、WSFC クラスターの各ノードのローカル Administrators グループのメンバーであるドメイン アカウントを使用する必要があります。
WSFC の強制クォーラムの手順による災害復旧
クォーラム障害が発生すると、クラスターの構成どおりにノード レベルのフォールト トレランスを確保できなくなるため、WSFC クラスター内のクラスター化されているサービス、SQL Server インスタンス、および AlwaysOn 可用性グループがすべてオフラインになります。 クォーラム障害は、WSFC クラスター内の正常な投票ノードがクォーラム モデルを満たさなくなったことを意味します。 ノードによって、まったく機能しなくなるものもあれば、WSFC サービスがシャットダウンしただけで、クォーラムと通信できなくなったことを除けば正常なものもあります。
WSFC クラスターをオンラインに戻すには、既存の構成でクォーラム障害の根本的な原因を解決し、影響を受けたデータベースを必要に応じて復元する必要があります。また、稼働しているクラスター トポロジを反映させるために、WSFC クラスター内の残りのノードの再構成が必要になることもあります。
WSFC クラスター ノードで強制クォーラムの手順を使用して、クラスターをオフラインにした安全管理を無効にすることができます。 これにより、クラスターでのクォーラム投票のチェックが実質的に中断され、クラスター内の任意のノードで WSFC クラスター リソースと SQL Server をオンラインに戻すことができます。
この種の災害復旧プロセスの手順を次に示します。
クォーラム障害から復旧するには:
**障害の範囲を特定します。**応答しない可用性グループや SQL Server インスタンス、災害後に使用できるオンラインのクラスター ノードをそれぞれ特定し、Windows イベント ログと SQL Server システム ログを確認します。 必要に応じて、後で分析できるように解析データやシステム ログを保存しておきます。
.gif "ヒント")
ヒント応答している SQL Server 2012 インスタンスで、sys.dm_hadr_availability_group_states 動的管理ビュー (DMV) クエリを実行して、ローカル サーバー インスタンスに可用性レプリカを保持している可用性グループの正常性に関する情報を取得できます。
**1 つのノードで強制クォーラムを使用して WSFC クラスターを起動します。**WSFC クラスター サービスがシャットダウンしたもの以外で、コンポーネントの障害が最も少ないノードを特定し、 そのノードが他の大半のノードと通信できることを確認します。
このノードで、強制クォーラムの手順に従って、クラスターを手動で強制的にオンラインにします。 データ損失の可能性を最小限に抑えるには、可用性グループのプライマリ レプリカを最後にホストしていたノードを選択します。
詳細については、「クォーラムを使用せずに WSFC クラスターを強制的に起動する」を参照してください。
注強制クォーラムの設定はクラスター全体に影響します。論理的 WSFC クラスターの投票が過半数に達し、通常のクォーラム モードの動作に自動的に切り替わるまで、クラスター全体のクォーラムのチェックがブロックされます。
**他の正常な各ノードで、一度に 1 つずつ、通常の方法で WSFC サービスを起動します。**他のノードでクラスター サービスを起動するときは、強制クォーラム オプションを指定する必要はありません。
各ノードの WSFC サービスがオンラインに戻ると、他の正常なノードとの間でネゴシエーションが行われ、新しいクラスター構成の状態が同期されます。 この手順は、クラスターの最新の状態を解決するときに競合状態が発生するのを回避するために、必ず一度に 1 つのノードで行うようにしてください。
注意起動した各ノードが新たにオンラインにした他のノードと通信できることを確認します。 他のノードでは WSFC サービスを無効にすることを検討してください。 そうしないと、クォーラム ノード セットが複数作成される可能性があります。これをスプリット ブレイン シナリオと呼びます。 手順 1. の結果に問題がなければ、この現象は発生しません。
**新しいクォーラム モードとノードの投票の構成を適用します。**クォーラムを強制することによってクラスターのすべてのノードが正常に再起動し、クォーラムのエラーの根本原因が修正された場合、元のクォーラム モードとノードの投票の構成に対する変更は必要ありません。
それ以外の場合は、新たに復元されたクラスター ノードと可用性レプリカ トポロジを評価し、必要に応じて各ノードのクォーラム モードと投票割り当てを変更します。 復元されていないノードについては、オフラインにするか、ノードの投票を 0 に設定する必要があります。
ヒントこの時点で、クラスター内のノードと SQL Server インスタンスが通常の動作に戻っているように見えることがありますが、 正常なクォーラムはまだ存在しない可能性があります。 フェールオーバー クラスター マネージャー、SQL Server Management Studio の AlwaysOn ダッシュボード、または適切な DMV を使用して、クォーラムが復元されたことを確認してください。
**必要に応じて、可用性グループのデータベース レプリカを復旧します。**可用性グループ以外のデータベースは、SQL Server の通常の起動処理の一環として個別に復旧されてオンラインに戻ります。
データ損失の可能性や可用性グループ レプリカの復旧時間を最小限に抑えるには、プライマリ レプリカ、同期セカンダリ レプリカ、非同期セカンダリ レプリカの順にオンラインに戻します。
**障害が発生したコンポーネントを修復するか交換し、クラスターを再検証します。**最初の災害およびクォーラム障害から復旧したので、障害が発生したノードを修復するか交換し、WSFC と AlwaysOn の関連する構成を適切に調整する必要があります。 これには、可用性グループ レプリカの削除、クラスターからのノードの削除、ノードへのソフトウェアの再インストールなどが含まれます。
停止したすべての可用性レプリカを修復または削除する必要があります。 SQL Server では、可用性レプリカよりもはるかに前の認識されている最後の時点からトランザクション ログが切り捨てられません。 可用性グループから停止したレプリカを修復または削除しないと、トランザクション ログが大きくなり、他のレプリカのトランザクション ログの領域が不足する可能性があります。
注WSFC クラスターに可用性グループ リスナーが存在するときに、WSFC の構成の検証ウィザードを実行すると、次のような誤った警告メッセージが生成されます。
"ネットワーク名 'Name:<network_name>' の RegisterAllProviderIP プロパティは 1 に設定されています。現在のクラスター構成の場合、この値は 0 に設定する必要があります。"
このメッセージは無視してください。
**必要に応じて手順 4. を繰り返します。**この目的は、正常な動作に対する適切なレベルのフォールト トレランスと高可用性を再確立することです。
**RPO/RTO 分析を実行します。**SQL Server システム ログ、データベースのタイムスタンプ、および Windows イベント ログを分析して、障害の根本的な原因を特定し、実際の復旧ポイントと復旧時間を文書化します。
![[トップに戻る] リンクで使用される矢印アイコン](images/ms175817.uparrow16x16(sql.110).gif "[トップに戻る] リンクで使用される矢印アイコン")
[先頭に戻る]
関連タスク
[先頭に戻る]
関連コンテンツ
[先頭に戻る]