本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「IPアドレスを変更したら、SQL Serverが起動しなくなった場合の対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:クラスタ環境の機器移設に伴い、SQL Serverが稼働しているサーバのIPアドレスを変更したところ、クラスタサービスとしてSQL Serverがオンラインにならず、正常に起動しなくなってしまった。
変更前のIPアドレスに戻して試すと、正常に起動する。
併せてSQL Serverのエラーログを確認すると、「変更後の仮想IPアドレス」を使って問題なく起動したと記載されている。実際には起動できていないのだが、SQL Server側にエラーの記録は見つからない。
今回はサーバのIPアドレス変更という、サーバ管理においてはよくある作業時のトラブル事例です。
IPアドレスを変更するとクラスタ構築でエラーが発生するが、IPアドレスの設定を元に戻せば直る。また、SQL Server側に正しく起動したとログが出力されているのに、実際には正しく起動できないという状態です。
ログにエラーが出力されていないことからSQL Server側の問題ではないようです。それよりも上位レイヤーであるOS側の状況はどうでしょうか。WindowsイベントビューアーでWindowsログの「システム」項目を確認すると、「エラー7034」が見つかりました(図1)。
記録されていた「エラー7034」には、「SQL Server (MSSQLSERVER) サービスは予期せぬ原因により終了しました。このサービスの強制終了は 1 回目です」とエラーメッセージの内容を確認できます。
続いてWindowsイベントビューアーでアプリケーションとサービスログ→Microsoft→Windows→「FailoverClustering」と進み、「Diagnostic」の項目を確認すると、同じ時間帯に「エラー2051」も記録されていました(図2)。
エラー2051には「[RES] SQL Server
これらのエラーメッセージから何が分かるのでしょうか。
SQL Serverはひとまず正常に起動しました。しかしOS側は、起動したSQL Serverに正しく接続できなかったので、SQL Serverが正しく起動したかどうかを識別できなかった。だからOS側では「SQL Serverは、予期せぬ原因によって終了したと判断した」という状況のようです。
今回の作業で変更したのはサーバのIPアドレスだけです。OSが不具合だと判断したならば、どこかに不整合の要因があるはずです。前述したように、SQL Serverのエラーログには「変更後の仮想IPアドレス」が記録されていました。ドメインコントローラーで確認したDNSのAレコードにも変更後の仮想IPアドレスが正しく登録されていました。
ところが、起動に失敗したクラスタノードで仮想マシン名に対して打った「ping」では、「変更前のIPアドレス」に対して接続を施行していました。念のため実行した「ipconfig /displaydns」でも、仮想マシン名には変更前のIPアドレスが表示されました。それは、DNAリゾルバキャッシュを消去する「ipconfig /flushdns」を実行しても変化はありませんでした。
DNSのAレコードは問題がないにもかかわらず、マシン名が変更後のIPアドレスとひも付かないのはなぜなのでしょう。
理由は単純でした。C:\Windows\System32\drivers\etcにある「hosts」ファイルに、仮想マシン名と変更前のIPアドレスがひも付いて記載されていたためです。
……つまり、DNSより先に参照されるhostsファイルに変更前のIPアドレスが明記されていたことから、変更後のIPアドレスを正しく反映できない状態になっていたということになります。
Copyright © ITmedia, Inc. All Rights Reserved.