“死のブルースクリーン”が発生したが、自動フェイルオーバーされなかった（フェイルオーバートラブル）：SQL Serverトラブルシューティング（35）（1/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「BSODが発生しても自動フェイルオーバーされなかった場合の対処方法」を解説します。

[椎名武史，ユニアデックス株式会社]

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

→この他のフェイルオーバーに関連するトラブルの実例を見る

トラブル 28（カテゴリー：フェイルオーバー）：BSODが発生しても自動フェイルオーバーされなかった

目次

• トラブルの実例
• トラブルの原因
• 解決方法

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの実例：2ノードのクラスタ環境で可用性グループを構築している。導入後の動作確認ではプライマリー側のWindows Serverを意図的にシャットダウンさせて、正常に自動フェイルオーバーされることを確認していた。

　しかし、いざ本当の障害でBSOD（Blue Screen of Death：死のブルースクリーン）が発生しても自動フェイルオーバーが機能せず、結果としてサービスが停止してしまった。

　WindowsイベントビューアーでWindows ログの「Application」の項目を確認すると、「エラー41092」が記録されていた（図28-1）。

図28-1　Windowsイベントビューアーで「エラー41092」を確認

目次に戻る

トラブルの原因を探る

　記録されていた「エラー41092」には、「Always On: the local Windows Server Failover Clustering (WSFC) node has lost quorum のため、可用性レプリカ マネージャーをオフラインに移行しています」とあります。「クォーラム（過半数に達する投票数）がない」ために、「可用性レプリカマネージャーが機能していなかった」ことが原因のようです。

　Windows Server 2012以降には、動的なクォーラム管理機能が実装されています。クォーラム管理機能により、各ノードの状態に基づいてノードへの投票の割り当てを動的に管理できるようになっています（*1）。

（*1）Windows Server 2012 フェールオーバー クラスターでクォーラムを構成および管理する（Microsoft Developer Network）

　2ノード構成では、この動的なクォーラム管理によって片ノードだけに投票権を持たせます（図28-2）。通常の方法でシャットダウンする（スタートメニューからシャットダウンを選択する）場合には、事前に投票権などを他のノードに動的に移動させてからシャットダウンします（図28-3）。

図28-2　フェールオーバー クラスター マネージャーで現在の投票状況を確認すると、「Node 1」のみが投票権を持っている

図28-3　シャットダウン時には、1つ目のノード「Node 1」が停止する前に、投票権が動的に2つ目のノード「Node 2」へ移動される

　しかし、投票権などを移動できない急な障害でシステムがダウンすると、上記の都合からクラスタとして動作できなくなるクォーラム障害が発生します。クォーラム障害は、システム障害や永続的な通信障害の他、WSFC（Windows Serverフェイルオーバークラスタリング）内の複数のノードにおける不適切な構成が原因で発生します。

目次に戻る