2013年8月28日水曜日

ibdファイルの肥大化の解消

以前に書いた記事のテーブルスペース肥大化の対処方法(ibdata*) と似たような現象ですが、
innodb_file_per_tableを設定した事で、テーブルスペースがテーブル事に作成され、
テーブルスペースの肥大化のリスクを軽減しましたが、
それでも1つのテーブルに大量のデータを登録し続けると肥大化してしまいます(´;ω;`)ウッ…

今回の例で言いますと、ログ関係のデータを長期間保存し続けた事によって、
1つのテーブルが肥大化してしまいました・・・orz

どのくらいかって言うと・・・1つのテーブルスペースファイルで262GBもありましたΣ(゚Д゚;エーッ!

-rw-rw---- 1 mysql mysql     50331648  8月 26 20:13 2013 ******.ibd
-rw-rw---- 1 mysql mysql 262030753792  8月 26 20:13 2013 operation_log.ibd
そのせいもありHDD総量の83%も使われてしまっている状態でした(; ・`д・´)
df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/sda2             443G  347G   74G  83% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             194M   53M  132M  29% /boot
とりあえず、実データを必要最小限のレコードのみにするため大量のレコードを削除しましたが、
一度大きくなってしまったibdファイルのテーブルスペースはデフラグをしないと小さくならない?っぽいです。

デフラグにはALTER TABLEを使うと、読み込みロックがかからなくて良いよ!とこちらの記事に書かれています。
ALTER TABLEを上手に使いこなそう。
コマンドの実行中もテーブルからREADが出来るからだ。テーブルが壊れた場合にはREPAIR TABLEコマンドを使うし、
最適化したい場合にはOPTIMIZE TABLEコマンドを使うのだが、これらのコマンドはWRITEだけでなくREADもブロックしてしまう。
従って、メンテナンス中にWRITEは出来なくてもREADだけは可能にしたい、というような場合には、
まずはALTER TABLEを試して見るといいだろう。
テーブル定義の変更をせずに、テーブルを再作成したい場合には、次のようにALTER TABLEコマンドを実行するといい。
ただし、注意点として次のような点もあるそうです。
そんなわけで、大きなテーブルをALTERするときには長時間WRITEがブロックされてしまうので注意しよう。
また、ALTER TABLEでは完全なテーブルのコピーを作成する必要があるので、
元のテーブルのサイズと同じぐらいのディスク空き容量が必要であることにも注意しなければいけない。
空き容量が足りないとALTER TABLEコマンドは失敗してしまう。
ALTER TABLEを使ったとしても書き込みロックがかかってしまうため、
現状のレプリケーションを行っている環境で数分書き込みロックがかかってしまうと致命的です。

そこで、本番環境から隔離した状態で行うことにしました。
HAProxyなどを利用している事もあり、slaveの隔離は簡単に行える状態になっていたので楽チン(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

HAProxyの設定などは以前のこちらの記事を参照してください。
slaveの負荷分散&フェイルオーバー(HAProxy)

実際にデフラグで行った手順を次になります。
下記の手順を隔離したサーバーごとに実行しました

実行した結果、約17分もかかりました・・・(; ・`д・´)
mysql> ALTER TABLE operation_log ENGINE InnoDB;
Query OK, 448088 rows affected (17 min 52.64 sec)
Records: 448088  Duplicates: 0  Warnings: 0
実際にibdファイルが小さくなったか確認してみます。
-rw-rw---- 1 mysql mysql 15338569728  8月 26 20:43 2013 operation_log.ibd
drwx------ 2 mysql mysql      184320  8月 26 20:37 2013 .
(゚∀゚)キタコレ!!
$ df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/sda2             443G  117G  303G  28% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             194M   53M  132M  29% /boot
HDDの使用率は一気に減りました( ´∀`)bグッ!

以上です(`・ω・´)ゞビシッ!!

0 件のコメント:

コメントを投稿