ログの肥大化に注意

VPSサーバーを構築していて、普段サイトにそんなにアクセスがないからとかで、ログファイルの削除をしていないと後に大変な事になります。ログの肥大化には注意を払っていきたいです。

突然起きたデータベースエラー

突然サイトに『Error establishing a database connection』とでました。このエラー文で検索したら以下のページがでてきました。

今まで繋がっていたのでホスト名が間違っているとかではなかったです。調べて見たらMySQLが落ちてました。普通に起動コマンドを打っても起動しませんでした。

エラーログを見る

/var/log/mysqld.logを見ました。色々なエラーとかが残っていたりして四苦八苦していましたが、最終的にはディスクの容量が一杯でMySQLが起動できないという結論でした。

※この結論たどりつくまで一日近くかかりました。単純に僕がもっと早く気づけばよかったのを遠回りしたからです。

ログを削除して起動

mysqld.logファイルを削除して、MySQLのコマンドをうったら起動できませんでした

Timeout error occurred trying to start MySQL Daemon.

起動できないのでエラーログを確認しました

tail /var/log/mysqld.log

すると以下のエラー文がでました。
mysqld started
[ERROR] Can't start server: Bind on TCP/IP port: Address already in use
[ERROR] Do you already have another mysqld server running on port: 3306 ?
[ERROR] Aborting

[Note] /usr/libexec/mysqld: Shutdown

mysqld ended

Do you already have another mysqld server running on port: 3306 ?で検索

検索すると、DBがいないとか色々でてきましたが、僕の場合は単純にMySQLが既に他のプロセスで動いているというだけでした。そこで以下のように確認しました。

/etc/init.d/mysqld status
mysqld (pid 12953 pid16334 pid192434) を実行中...
※idは適当です

Killコマンドで強制停止

kill プロセスIDと打ったのですが、ききませんした。参考サイトを見てkill -9 プロセスID にしたらMySQLが強制停止しました。

参考サイト:http://linuxtips.sblo.jp/article/32054710.html

ログを削除してディスクの空き容量を確保

MySQLのログを削除しても改善されませんでした。ディスクの空き容量は全然増えませんでした。このサイトはアクセス数がかなりあるのでそっちではないかと思い、アクセスログとエラーログを削除しました。

ログの削除でMySQL起動

ログを削除したらMySQLが起動しました。今回はログをアクセスログとエラーログでよかったのですが、調べていたらMySQLはバイナリログヲ定期的に削除する設定ではないそうなので、念のためログの削除を設定しました。

MySQLのバイナリログの削除設定

my.confに以下の設定を追記して再起動しました。

vi /etc/my.conf
expire_logs_days = 5

/etc/init.d/mysqld restart

確認はMySQLにログインをして以下のコマンドで見れます

#mysql -u root -p
mysql> SHOW GLOBAL VARIABLES like ‘expire_logs_days’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| expire_logs_days | 5 |
+——————+——-+

これで設定変更完了です。5日で自動で削除されます。

参考サイト:MySQLでバイナリログを定期的に削除するmy.cnfの設定(expire_logs_days)

備考

ログの肥大化するとサイトが閲覧できなくなるため、定期的に削除または移動することをお勧めします。また、今回強制的にサーバーを停止したこともあり、データベースが壊れてしまいました。以下のコマンドを使ってチェックと修復しました。

check table ここにチェックするテーブル名を入れる
チェック後、errorやwarningがでたら以下のコマンドを入れる

repair table ここに修復するテーブル名を入れる
修復ができたらstatus OKとでるのを確認する

その後もう一度チェックをしてstatus OKだったら終了

今後はログを1日ごとに移したりしないといけないので考えないとです・・もっと早くログの肥大化に気づいて対応していれば今回のような障害はおきなかったので今後は注意していきます。