「ブログ記事が突然消えた？| なぜか、not Foundに」の続きです。
WordPressやMySQLは関係なく、システムが100%で容量不足が原因だと前回お伝えしました。
じゃあ、なぜ急に容量不足になったのか、容量が肥大したものは何なのか調べてみた。
せめて、先月までは、全然余裕だったルート(/)領域だったので、どこかcore吐いてる？と予想しながら、探してみたら、/var/lib/mysql/内のibdata1,ib_logfile0,ib_logfile1が、かなり大きい容量になっているのを発見。
ibdata1って何？ 消してもええのけ？
などと、ググってみる。ibdata1とは？
ふむふむ、InnoDBのデータなのか。
で、削除方法とかは、「Mysqlのibdata1サイズの圧縮。」や「ibdata1 のサイズを減らす手順」他を参考にさせていもらいました。（感謝）
では、早速削除・修復作業に入る。
- mysqlのデータをバックアップ
# mysqldump -u root -p –all-databases > dump.sql (全DBのバックアップ)
(# mysqldump -u root -p wordpress_db > wordpress.sql ←WordPressのDBだけバックアップ ) - InnoDBを利用しているデータベースを削除
mysql> drop databases <データベース>;
ちなみに、mysqlとinformation_schema、performance_schemaは消さなかった。 - MySQL停止
# service mysqld stop - /var/lib/mysql/内の、ibdata1,ib_logfile0,ib_logfile1を削除もしくは移動
- /etc/my.cnfのmysqld内に下記を追記
innodb_data_file_path = ibdata1:1G
innodb_file_per_table - mysql起動
# service mysqld start
再度、削除したibdata1が再作成されるので、少し時間がかかる - バックアップしたデータベースをリストア
#mysql -u root -p wordpress < wordpress.sql
データベースを削除したりするので、元に戻らなかったらどうしよう？などの不安はありましたが、何とか、無事復旧しました。(^^ゞ
でも、安心するのは、まだ早い！
実は、復旧後のシステム環境を見てみると、100%だった容量が、95%と、変化が乏しい。
これでは、近いうちに、また不安定になるし、根本的に解決になってない。
最近、ブログへのログインや投稿で、やたらと時間がかかっていたのは、この容量不足が原因だったと思うが、何となく、php-fpmの負荷が多いのが気にはなっていた。
実は、/var/log/php-fpm/内のエラーログが半端なく容量を食っていたと言う落ち！(>_<)
容量不足→MySQLエラー→php-fpmエラーログ吐くの悪循環であった。
コメント