SQL Serverが正しく再起動しなくなってしまった（起動トラブル）：SQL Serverトラブルシューティング（11）

トラブルの実例：システムの可用性をテストするために、WindowsのタスクマネージャーからSQL Serverプロセスを強制的に終了させて、意図的に障害を発生させた。

　当初は、強制的に終了させたSQL Serverが正常に再起動されることを確認したが、ある段階で自動的に再起動しなくなってしまった。フェールオーバー クラスター マネージャーで確認すると、SQL Serverのリソースに「失敗」と表示されていた（図6-1）。

図6-1　フェールオーバー クラスター マネージャーで確認すると、SQL Serverのリソースが「失敗」と表示されていた

トラブルの原因を探る

　Windowsのシステムログ（「イベントビューアー」→「Windows ログ」→「システム」）を確認すると、エラー1254の「クラスター化された役割’SQL Server(MSSQLSERVER)’がフェールオーバーのしきい値を超えました。割り当てられたフェールオーバー期間内に試行できる構成済みのフェールオーバー回数の上限に達したため、エラー状態のままとなります」というメッセージが記録されていました（図6-2）。

図6-2　Windowsのシステムログを確認すると、「エラー1254」が発生していた

　「構成済みのフェールオーバー回数の上限」について、フェールオーバー クラスター マネージャーから設定内容を確認してみます（図6-3）。

図6-3　フェールオーバー回数は、指定した期間内の最大エラー数が「1」、期間は「6時間」で設定されていた

　今回の例では、2ノードでクラスタを構築しています。そして上記の設定は、6時間に1回までのエラー（エラーテストの実施も含む）ならば、通常通り再起動を試みます。しかし、2回以上エラーが発生したら「もう無理（再起動するだけでは直らない）」とみなし、再起動をせずに「失敗した状態のままにする設定」となっていることが分かりました。

　これは、意図したエラーテストであっても……1回とカウントされます。入念に準備したがゆえに発生してしまう、意外な落とし穴となるトラブルです。

解決方法

　この「もう無理」とみなす“しきい値”である「エラー回数」と「判定期間」を、図6-3のフェールオーバー クラスター マネージャーより変更します。テスト時には、エラー回数を少し多めにするか、期間を短めにしておくとよいでしょう。ちなみにエラー回数は、クラスターサービスを再起動することでもリセットできます。

　なお、このトラブルは、フェールオーバー クラスターの機能を使う「AlwaysOn可用性グループ」でもよく発生するので、ご注意ください（*1）。