WordPressのサーバ障害対応の記録
2014年11月12日
今日は、管理しているホームページのサーバに謎の障害が発生し、対応が大変でした。
何とか対応することができたので、備忘録も兼ねて対応の記録を書いておきます。
起きた障害の状況
WordPressのホームページが突然ダウンしてしまい、アクセス不可に。
データベース接続エラーという状況。
原因
サーバのディスク容量がMAXに達していました。
どうしてわかったかというと、FTPでアップしたファイルが全て0バイトになってアップされてしまい、アップできない。
それどころか、アップしたファイルで上書きをしたファイルが破損してしまう。
これは何故か調べてみると、容量がないときに発生する現象ということでした。
さらにディスク容量がマックスのため、データベース接続で問題が発生してしまっていたようでした。
対処法
1.サーバにある不要なファイルを削除
サーバ上の不要なファイルを削除しました。
サーバ上の不要なファイルの見つけ方
コマンドラインで
df -h
これで、まず現在のディスクの使用量が確認できます。いっぱいになっている場合は対処が必要です。
(今回のケースでは100%の使用になっており、早急に対処が必要な状況でした。)
容量を多く使っているディレクトリの見つけ方
du / | sort -nr | head -30
これで、サーバ上の容量の多い上位30のディレクトリを順に出力されます。
確認したところ
/var/log/httpd/
と、Apacheのログファイルのフォルダがほとんどディスク容量を使い切ってる状態でした。
そのため、過去の不要なログファイルを削除して、容量を確保しました。
2.データベースの修復
しかし、ディスク容量を確保しましたが、WordPressのデータベースが破損していて、トップページにアクセスしてもデータベース接続不可。
/wp-admin/にアクセスすると、「データベースの修復が必要」とメッセージが表示されました。
この時点で、phpmyadminにはアクセスできるようになっていたので、念のためデータベースのバックアップ後、データベースの修復を行いました。
データベースの修復は、wp-config.php に define(‘WP_ALLOW_REPAIR’, true); を追加後 /wp-admin/ にアクセスすると修復が必要なテーブルが表示されるので、あとはコマンドラインからMySQLに接続後、
repair table テーブル名;
とコマンドを実行して修正が必要なテーブルを修復します。
すると、これでサイトにアクセスすると無事表示されるようになっていました。
今後の対策
今回問題が起きた原因として、Apacheのログファイルが知らない間に肥大化し、ディスク容量を使いきってしまっていたことにありました。
そのため、まずは対策として、Apacheのログファイルの出力に制限をかける必要があります。
その上で、ディスク容量が危なくなってくると管理者にメールで通知するような仕組みが構築できればなおベストでしょう。
また、今回はデータベースが修復できたので良かったですが、もし破損してしまい修復できないと本当にどうしようもない事態に陥っていた可能性もあるので、念のためデータベースのバックアップをcronで組んでおくことも必要といえそうです。
今思えば・・・
今回起きた状況の事前の状況として、事前にフラグと思えるような現象が起きていました。
1.phpmyadminで画面が真っ白
phpmyadminにアクセスすると、画面が真っ白になりアクセスできず、原因が不明でした。
これも原因がディスク空き容量が少ないことが原因だったようです。
2・FTPで転送できない
あるタイミングから突然FTPでファイルが転送できなくなっていました。
これもディスク容量に空きがないことが原因でした。
このあたりで早めに気がつくことができれば事前に防ぐことができたかもしれないですが、これまでこういった現象に遭遇したことがないので気が付きませんでした。