9/2 10:41から本ブログがアクセス不可になっていた。現在は復旧したが、気付くのが遅れてしまい3日間ブログがダウンした状態だった。
ブログ訪問者の方にはご迷惑をお掛けしました。
以下、原因調査から復旧、今後の対策について考えた話。
あれ、ブログに繋がらないじゃん
特に定期的に確認しているわけではないが、日頃からGoogle Analyticsでブログのアクセス解析を眺めたりしている。最近アクセス数が激減しているのはなんでだろうとブログのURLにアクセスしてみたところ、「データベース接続確立エラー」が表示されブログにアクセスできなかった。
原因調査
本ブログは、DTIのServersMan@VPS上にApacheとMySQLでWordPressを動かしている。ブログにアクセスすとHTMLのレスポンスは返ってくるのでApacheの問題では無いと考えられる。そこでMySQLについて調査してみる。
$ ps -ef |grep mysqld | grep -v grep $
psコマンドを打ってみたところ、MySQLのプロセスが起動していない。
次に、MySQLのログを確認。
# cat /var/log/mysqld.log 〜略〜 140902 10:41:14 [Note] /usr/libexec/mysqld: Normal shutdown 140902 10:41:14 [Note] Event Scheduler: Purging the queue. 0 events 140902 10:41:14 InnoDB: Starting shutdown... 140902 10:41:17 InnoDB: Shutdown completed; log sequence number 0 44243 140902 10:41:17 [Note] /usr/libexec/mysqld: Shutdown complete 140902 10:41:17 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
MySQLのプロセスがシャットダウンされた記録が残っていた。ひとまず、MySQLを起動し直してブログのほうは復旧完了。
# /sbin/service mysqld start Starting mysqld: [ OK ]
でも、プロセスがいきなり落ちた訳ではなくシャットダウンの処理が行なわれている事が不可解だった。ハッキングでもされたのかとちょっとビビる。
原因は意外なところに
色々調べているうちに、ふとOSの再起動を疑ってみた。uptimeを確認してみたところ、やはり再起動の形跡がある。再起動日もアクセスが減った日と合致する。
# uptime 00:52:11 up 3 days
MySQLの自動起動が有効化されていなかったので、OSが再起動された段階でMySQLが起動せずそのままだったのが今回のトラブルの原因と分かった。
ちなみに、サーバ再起動についてはDTIのサーバメンテナンスによるものであった。
http://info.dream.jp/information/20140811_12382.html
今後の対策
まず、OS再起動が行なわれても自動でMySQLが復旧される仕組みが必要である。以下の設定を行なった。
# chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig mysqld on # chkconfig --list mysqld mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off
後は、ミドルウェアのプロセスが止まったりOSが再起動したときにメールで通知されるように監視システムを構築したいなーと考えている。Zabbixやnagiosあたりがいいのかな。
監視サーバ用にVPSをもう1台契約するのはコストが掛かるし、自宅に固定回線が無いので何か代替手段は無いかと模索している。