画像やリンクが無効になっている可能性もあるのでご了承下さい。
ずっと前から肥大化に気付いては居たけど、それとなく放置していた状態が続いていた。気がつくと 4GB 近くになっていたから流石に対処する事とした。
DB のサイズ次第では時間がかかるので億劫だからサボっていたとも言うのだが……
作業前に何かあっても直ぐ対処出来る様にバックアップを取っておく。これは MUST で。と言うか後で使う。
一応 DB が更新されたりするとアレだからアクセスしてくる物を止めておく。今回は apache だけ止めた。
ホストは CentOS 6 だから下記のオペレーションだけど 7 なら systemctl stop httpd だとかして任意に止める。
service httpd stop
続いてバックアップ取得。オプションでは -x を付けて全 DB の全 Table を Lock しつつ行う。バックアップ先は任意で空きのあるスライスにしておく。
mysqldump -u root -p -x --opt --all-databases > /var/tmp/all_db.sql
MySQL を一旦止めて ibdata, ib_logfile を削除する。
ls -l でワイルドカードでフィルタされるファイル群が削除すべきファイルか確認しておく。これは個人的な癖だけど書いておく事に。
実際の削除は一旦どこかへ移動させておくことで MySQL に見せなくしている。
service mysqld stop
ls -l /var/lib/mysql/ib*
(削除するファイルのリストを確実に確認する)
mv /var/lib/mysql/ib* /var/tmp/
完了したら MySQL を起動させて最初に取った SQL のバックアップを流し込む。
もし、この時 MySQL が起動しなければ 1 つ前で移動させた ib* を全て /var/lib/mysql/ 以下にまた戻して作業は中止する。
service mysql start
mysql -u root -p < /var/tmp/all_db.sql
ここまでエラー無しで終わっていれば正常と見なす。
止めていた apache を起動して DB を扱うホストにアクセスして動作確認を行う。
service start httpd
以上で完了。
改めて ibdata1 をみたら、4GB 近くあったものが 626MB と表示された。無事に肥大化を解消する事が出来た。
2016/05/30 13:35 追記
バックアップ取得後の文にて、「ibdata1 なんかを」と曖昧な書き方をしつつオペレーションでワイルドカードを記述するような内容だったので、削除すべきファイル名を明記した。
コメント
「この時MySQL が起動しなければ・・・戻して作業は中止」とありますが、その時にibdata1の肥大化にはもう対策はないのですかねぇ
「起動しなければ」と書いたので、やはり過去にそう言った経験があります。それ以上の事が「分からなかった」ので起動しなかった場合の確実な改善方法は今も分からないままです。
なぜこの記事を書いた時には正常に出来たのかも MySQL に関しては殆ど知識がなくてなんとも… ですが、ALTER TABLE で InnoDB の絡む DB を最適化したりと必死にやっていた記憶もあります。
今もちょっと検索なりしてみましたが、最終段階の MySQL 起動で転ける場合に関しての情報はみつかりませんでした。
なんともお役に立たないお話しで申し訳ございませんorz