SQL Serverの可用性グループがフェイルオーバーしたが、発生した原因が分からない（フェイルオーバートラブル）：SQL Serverトラブルシューティング（33）（1/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「可用性グループでフェイルオーバーが発生した原因の一例」を解説します。

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

連載バックナンバー

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

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

トラブル 26（カテゴリー：フェイルオーバー）：SQL Serverの可用性グループがフェイルオーバーしたが、発生した原因が分からない

目次

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

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

トラブルの実例：SQL Serverの可用性グループを構築した環境で運用しており、アプリケーションの改修作業を実施。しばらくすると、全てのインスタンスが正常稼働しているにもかかわらず、可用性グループのフェイルオーバーが発生した。

　旧プライマリー側のエラーログを確認したところ、直前までにSQL Serverのダンプが何度も出力されていたが、可用性グループについてはフェイルオーバーされた結果ログだけしかなく、発生した原因は記録されていなかった。

　一応、フェイルオーバー後は正常稼働しているものの、「なぜフェイルオーバーが発生したか」の原因が不明なため、フェイルバックして問題ないかを判断できない。

目次に戻る

トラブルの原因を探る

　SQL Serverの可用性グループで何か問題が発生した場合は、普段確認するエラーログやWindowsイベントビューアーだけでなく、エラーログと同じディレクトリに格納されている「SQLDIAG（AlwaysOn Health Diagnostics Log）」（*1）の拡張イベント（*2）も合わせて確認するようにします。

（*1）AlwaysOn Health Diagnostics Logとは（Microsoft Developer Network）

（*2）拡張イベントとは（Microsoft Developer Network）

　例えば、SQLDIAGの「＜ホスト名＞_＜インスタンス名＞_SQLDIAG_X_XXXXXXXXX.xel」というファイルを「SQL Server Management Studio」で開くと、可用性グループの正常性チェックの様子と、その結果に伴うメッセージを確認できます。

　今回の事例では、フェイルオーバーが発生した時間帯に「Failure detected, the state of system component is error.」というメッセージが記録されていました（図26-1）。

図26-1　systemコンポーネントでエラーが記録されていた

　なお、可用性グループでは、自動的にフェイルオーバーする場合のエラー条件レベル（重要度別のしきい値）を変更できます。初期設定では、SQL Serverのサービス停止や無応答だった場合、もしくは正常性チェック／systemの項目でエラーが返された場合に自動フェイルオーバー（*3）を行います。正常性チェック／systemの項目でエラーが返されるシーンには、「孤立したスピンロック」「深刻な書き込みアクセス違反」「ダンプが多すぎる」などが挙げられます（*4）。

（*3）フェールオーバー クラスター インスタンスのフェールオーバー ポリシー（Microsoft Developer Network）

（*4）可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー（SQL Server）（Microsoft Developer Network）

　今回は、自動的にフェイルオーバーを行うエラー条件レベルが初期設定であること、正常性チェック／systemの項目でエラーとして記録されるダンプが多く発生していたことから、そのしきい値を超え、自動的にフェイルオーバーされたと考えられます。

目次に戻る