WSFC の強制クォーラムによる災害復旧 (SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

クォーラム障害は、通常、システム障害、永続的な通信障害、または WSFC クラスター内の複数のノードにおける不適切な構成が原因で発生します。Quorum failure is usually caused by a systemic disaster, or a persistent communications failure, or a misconfiguration involving several nodes in the WSFC cluster. クォーラム障害からの復旧には、手動による介入が必要になります。Manual intervention is required to recovery from a quorum failure.

開始前の準備Before You Start

前提条件Prerequisites

強制クォーラムの手順では、クォーラム障害の発生前に、正常なクォーラムが存在していたことを前提としています。The Forced Quorum Procedure assumes that a healthy quorum existed before the quorum failure.

警告

ユーザーは、Windows Server フェールオーバー クラスタリング、WSFC クォーラム モデル、 SQL ServerSQL Server、および環境に固有の配置構成の概念および操作に関する十分な知識を持っている必要があります。The user should be well-informed on the concepts and interactions of Windows Server Failover Clustering, WSFC Quorum Models, SQL ServerSQL Server, and the environment's specific deployment configuration.

詳細については、以下をご覧ください。「Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server」、「WSFC クォーラム モードと投票の構成 (SQL Server)For more information, see: Windows Server Failover Clustering (WSFC) with SQL Server, WSFC Quorum Modes and Voting Configuration (SQL Server)

セキュリティSecurity

ユーザーは、WSFC クラスターの各ノードのローカル Administrators グループのメンバーであるドメイン アカウントを使用する必要があります。The user must be a domain account that is member of the local Administrators group on each node of the WSFC cluster.

WSFC の強制クォーラムの手順による災害復旧WSFC Disaster Recovery through the Forced Quorum Procedure

クォーラム障害が発生すると、クラスターの構成どおりにノード レベルのフォールト トレランスを確保できなくなるため、WSFC クラスター内のクラスター化されているサービス、SQL Server インスタンス、および Always On 可用性グループAlways On availability groupsがすべてオフラインになります。Remember that quorum failure will cause all clustered services, SQL Server instances, and Always On 可用性グループAlways On availability groups, in the WSFC cluster to be set offline, because the cluster, as configured, cannot ensure node-level fault tolerance. クォーラム障害は、WSFC クラスター内の正常な投票ノードがクォーラム モデルを満たさなくなったことを意味します。A quorum failure means that healthy voting nodes in the WSFC cluster no longer satisfy the quorum model. ノードによって、まったく機能しなくなるものもあれば、WSFC サービスがシャットダウンしただけで、クォーラムと通信できなくなったことを除けば正常なものもあります。Some nodes may have failed completely, and some may have just shut down the WSFC service and are otherwise healthy, except for the loss of the ability to communicate with a quorum.

WSFC クラスターをオンラインに戻すには、既存の構成でクォーラム障害の根本的な原因を解決し、影響を受けたデータベースを必要に応じて復元する必要があります。また、稼働しているクラスター トポロジを反映させるために、WSFC クラスター内の残りのノードの再構成が必要になることもあります。To bring the WSFC cluster back online, you must correct the root cause of the quorum failure under the existing configuration, recover the affected databases as needed, and you may want to reconfigure the remaining nodes in the WSFC cluster to reflect the surviving cluster topology.

WSFC クラスター ノードで 強制クォーラム の手順を使用して、クラスターをオフラインにした安全管理をオーバーライドすることができます。You can use the forced quorum procedure on a WSFC cluster node to override the safety controls that took the cluster offline. これにより、クラスターでのクォーラム投票のチェックが実質的に中断され、クラスター内の任意のノードで WSFC クラスター リソースと SQL Server をオンラインに戻すことができます。This effectively tells the cluster to suspend the quorum voting checks, and lets you bring the WSFC cluster resources and SQL Server back online on any of the nodes in the cluster.

この種のディザスター リカバリー プロセスの手順を次に示します。This type of disaster recovery process should include the following steps:

クォーラム障害から復旧するには:To Recover from Quorum Failure:

  1. 障害の範囲を特定します。Determine the scope of the failure. 応答しない可用性グループや SQL Server インスタンス、災害後に使用できるオンラインのクラスター ノードをそれぞれ特定し、Windows イベント ログと SQL Server システム ログを確認します。Identify which availability groups or SQL Server instances are non-responsive, which cluster nodes are online and available for post-disaster use, and examine the Windows event logs and the SQL Server system logs. 必要に応じて、後で分析できるように解析データやシステム ログを保存しておきます。Where practical, you should preserve forensic data and system logs for later analysis.

    ヒント

    応答している SQL Server 2017SQL Server 2017インスタンスで、 sys.dm_hadr_availability_group_states 動的管理ビュー (DMV) クエリを実行して、ローカル サーバー インスタンスに可用性レプリカを保持している可用性グループの正常性に関する情報を取得できます。On a responsive instance of SQL Server 2017SQL Server 2017, you can obtain information about the health of availability groups that possess an availability replica on the local server instance by querying the sys.dm_hadr_availability_group_states dynamic management view (DMV).

  2. 1 つのノードで強制クォーラムを使用して WSFC クラスターを起動します。Start the WSFC cluster by using forced quorum on a single node. WSFC クラスター サービスがシャットダウンしたもの以外で、コンポーネントの障害が最も少ないノードを特定し、Identify a node with a minimal number of component failures, other than that the WSFC cluster service was shut down. そのノードが他の大半のノードと通信できることを確認します。Verify that this node can communicate with a majority of the other nodes.

    このノードで、強制クォーラムの手順に従って、クラスターを手動で強制的にオンラインにします。On this node, manually force the cluster to come online using the forced quorum procedure. データ損失の可能性を最小限に抑えるには、可用性グループのプライマリ レプリカを最後にホストしていたノードを選択します。To minimize potential data loss, select a node that was last hosting an availability group primary replica.

    詳細については、以下をご覧ください。クォーラムを使用せずに WSFC クラスターを強制的に起動するFor more information, see: Force a WSFC Cluster to Start Without a Quorum

    注意

    強制クォーラムの設定はクラスター全体に影響します。論理的 WSFC クラスターの投票が過半数に達し、通常のクォーラム モードの動作に自動的に切り替わるまで、クラスター全体のクォーラムのチェックがブロックされます。The forced quorum setting has a cluster-wide affect to block quorum checks until the logical WSFC cluster achieves a majority of votes and automatically transitions to a regular quorum mode of operation.

  3. 他の正常な各ノードで、一度に 1 つずつ、通常の方法で WSFC サービスを起動します。Start the WSFC service normally on each otherwise healthy node, one at a time. 他のノードでクラスター サービスを起動するときは、強制クォーラム オプションを指定する必要はありません。You do not have to specify the forced quorum option when you start the cluster service on the other nodes.

    各ノードの WSFC サービスがオンラインに戻ると、他の正常なノードとの間でネゴシエーションが行われ、新しいクラスター構成の状態が同期されます。As the WSFC service on each node comes back online, it negotiates with the other healthy nodes to synchronize the new cluster configuration state. この手順は、クラスターの最新の状態を解決するときに競合状態が発生するのを回避するために、必ず一度に 1 つのノードで行うようにしてください。Remember to do this one node at a time to prevent potential race conditions in resolving the last known state of the cluster.

    警告

    起動した各ノードが新たにオンラインにした他のノードと通信できることを確認します。Ensure that each node that you start can communicate with the other newly online nodes. 他のノードでは WSFC サービスを無効にすることを検討してください。Consider disabling the WSFC service on the other nodes. そうしないと、クォーラム ノード セットが複数作成される可能性があります。これをスプリット ブレイン シナリオと呼びます。Otherwise, you run the risk of creating more than one quorum node set; that is a split-brain scenario. 手順 1. の結果に問題がなければ、この現象は発生しません。If your findings in step 1 were accurate, this should not occur.

  4. 新しいクォーラム モードとノードの投票の構成を適用します。Apply new quorum mode and node vote configuration. クォーラムを強制することによってクラスターのすべてのノードが正常に再起動し、クォーラムのエラーの根本原因が修正された場合、元のクォーラム モードとノードの投票の構成に対する変更は必要ありません。If forcing quorum successfully restarted all the nodes in the cluster and the root cause of the quorum failure has been corrected, changes to the original quorum mode and node vote configuration are unnecessary.

    それ以外の場合は、新たに復元されたクラスター ノードと可用性レプリカ トポロジを評価し、必要に応じて各ノードのクォーラム モードと投票割り当てを変更します。Otherwise, you should evaluate the newly recovered cluster node and availability replica topology, and change the quorum mode and vote assignments for each node as appropriate. 復元されていないノードについては、オフラインにするか、ノードの投票を 0 に設定する必要があります。Un-recovered nodes should be set offline or have their node votes set to zero.

    ヒント

    この時点で、クラスター内のノードと SQL Server インスタンスが通常の動作に戻っているように見えることがありますが、At this point, the nodes and SQL Server instances in the cluster may appear to be restored back to regular operation. 正常なクォーラムはまだ存在しない可能性があります。However, a healthy quorum may still not exist. フェールオーバー クラスター マネージャー、SQL Server Management Studio の AlwaysOn ダッシュボード、または適切な DMV を使用して、クォーラムが復元されたことを確認してください。Using the Failover Cluster Manager, or the Always On Dashboard within SQL Server Management Studio, or the appropriate DMVs, verify that a quorum has been restored.

  5. 必要に応じて、可用性グループのデータベース レプリカを復旧します。Recover availability group database replicas as needed. 可用性グループ以外のデータベースは、SQL Server の通常の起動処理の一環として個別に復旧されてオンラインに戻ります。Non-availability group databases should recover and come back online on their own as part of the regular SQL Server startup process.

    データ損失の可能性や可用性グループ レプリカの復旧時間を最小限に抑えるには、プライマリ レプリカ、同期セカンダリ レプリカ、非同期セカンダリ レプリカの順にオンラインに戻します。You can minimize potential data loss and recovery time for the availability group replicas by bringing them back online in this sequence: primary replica, synchronous secondary replicas, asynchronous secondary replicas.

  6. 障害が発生したコンポーネントを修復するか交換し、クラスターを再検証します。Repair or replace failed components and re-validate cluster. 最初の災害およびクォーラム障害から復旧したので、障害が発生したノードを修復するか交換し、WSFC と AlwaysOn の関連する構成を適切に調整する必要があります。Now that you have recovered from the initial disaster and quorum failure, you should repair or replace the failed nodes and adjust related WSFC and Always On configurations accordingly. これには、可用性グループ レプリカの削除、クラスターからのノードの削除、ノードへのソフトウェアの再インストールなどが含まれます。This can include dropping availability group replicas, evicting nodes from the cluster, or flattening and re-installing software on a node.

    停止したすべての可用性レプリカを修復または削除する必要があります。You must repair or remove all failed availability replicas. SQL ServerSQL Server では、可用性レプリカよりもはるかに前の認識されている最後の時点からトランザクション ログが切り捨てられません。will not truncate the transaction log past the last known point of the farthest behind availability replica. 可用性グループから停止したレプリカを修復または削除しないと、トランザクション ログが大きくなり、他のレプリカのトランザクション ログの領域が不足する可能性があります。If a failed replica is not repaired or removed from the availability group, the transaction logs will grow and you will run the risk of running out of transaction log space on the other replicas.

    注意

    WSFC クラスターに可用性グループ リスナーが存在するときに、WSFC の構成の検証ウィザードを実行すると、次のような誤った警告メッセージが生成されます。If you run the WSFC Validate a Configuration Wizard when an availability group listener exists on the WSFC cluster, the wizard generates the following incorrect warning message:

    "ネットワーク名 'Name:<network_name>' の RegisterAllProviderIP プロパティは 1 に設定されています。現在のクラスター構成の場合、この値は 0 に設定する必要があります。""The RegisterAllProviderIP property for network name 'Name:<network_name>' is set to 1 For the current cluster configuration this value should be set to 0."

    このメッセージは無視してください。Please ignore this message.

  7. 必要に応じて手順 4. を繰り返します。Repeat step 4 as needed. この目的は、正常な動作に対する適切なレベルのフォールト トレランスと高可用性を再確立することです。The goal is to re-establish the appropriate level of fault tolerance and high availability for healthy operations.

  8. RPO/RTO 分析を実行します。Conduct RPO/RTO analysis. SQL Server システム ログ、データベースのタイムスタンプ、および Windows イベント ログを分析して、障害の根本的な原因を特定し、実際の復旧ポイントと復旧時間を文書化します。You should analyze SQL Server system logs, database timestamps, and Windows event logs to determine root cause of the failure, and to document actual recovery point and recovery time experiences.

関連タスクRelated Tasks

関連コンテンツRelated Content

参照See Also

Windows Server フェールオーバー クラスタリング (WSFC) と SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server