“死のブルースクリーン”が発生したが、自動フェイルオーバーされなかった(フェイルオーバートラブル):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)。
トラブルの原因を探る
記録されていた「エラー41092」には、「Always On: the local Windows Server Failover Clustering (WSFC) node has lost quorum のため、可用性レプリカ マネージャーをオフラインに移行しています」とあります。「クォーラム(過半数に達する投票数)がない」ために、「可用性レプリカマネージャーが機能していなかった」ことが原因のようです。
Windows Server 2012以降には、動的なクォーラム管理機能が実装されています。クォーラム管理機能により、各ノードの状態に基づいてノードへの投票の割り当てを動的に管理できるようになっています(*1)。
2ノード構成では、この動的なクォーラム管理によって片ノードだけに投票権を持たせます(図28-2)。通常の方法でシャットダウンする(スタートメニューからシャットダウンを選択する)場合には、事前に投票権などを他のノードに動的に移動させてからシャットダウンします(図28-3)。
しかし、投票権などを移動できない急な障害でシステムがダウンすると、上記の都合からクラスタとして動作できなくなるクォーラム障害が発生します。クォーラム障害は、システム障害や永続的な通信障害の他、WSFC(Windows Serverフェイルオーバークラスタリング)内の複数のノードにおける不適切な構成が原因で発生します。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 「SQL Server 2016」に搭載される新たなセキュリティ対策を追う
パブリックプレビューが公開されているマイクロソフトのRDB次期版「SQL Server 2016」。特徴の1つとするセキュリティ対策機能のポイントと目指すところをキーパーソンに聞いた。 - そもそも、リレーショナルデータベースとは何か?
データベースを基礎から勉強し理解を深めていくことは簡単なことではありません。本連載では、データベースに対するハードルを少しでも低くするために、初心者の方に必要なデータベースの基本から、障害対策やチューニングといった実践に即した内容までを幅広く解説していきます。今回は、データベースの役割と、それを管理するソフトウェアであるDBMSの基本機能について解説します。【更新】 - データの登録を行うINSERT文
- 複数の条件を指定してSELECT文を実行する
前回は、SELECT文の初歩の初歩を解説しました。今回は、複数の条件を指定して、目的のデータを取り出す方法を解説します(編集部) - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。