データベース障害(その3)

恒例の!?データベース障害です。

 

========関連記事========

昨日、治ったとか言っていたテーブルがまたもやエラーを吐きました。(泣)
本日の症状は、CPU使用率が100%に張り付いて、killしたらテーブル壊れてるっていう状態です。
repair table xxx;
でダメだったので、他の方法を探してみると
myisamchk -r /DBの絶対パス/テーブル名
という方法でいけるみたいなので、早速試してみたんですが
sort_buffer_size too small
とか怒られたので
myisamchk -o -f /DBの絶対パス/テーブル名
でコマンドは通って、テーブルは修復できたように見えたんですが、インデックスファイルが壊れたままみたいで検索しても結果が0件という状態です。
さらに調べてみるとFULLTEXTインデックスを使用している場合は
my.cnfの設定に合わせてft_min_word_lenを指定してやらんとダメみたいです。
ついでにmyisamchkのオプションについても調べてみるとsort_buffer_sizeも指定できるみたいなんで、
myisamchk -r –sort_buffer_size=6500M –ft_min_word_len=3 /DBの絶対パス/テーブル名
でイケました。
(sort_buffer_sizeはメモリ搭載量に応じて変更してください)
(ft_min_word_lenはmy.cnfの設定に合わせて下さい)
コマンドが通ると
テーブル名.TMDファイルの作成が始まって、一時テーブルデータの作成が始まります
昨日のブログにも書きましたがディスクに対象テーブルと同容量の空きが必要なんで注意が必要です。
作成が終わると、ファイルのスキャンらしきものを行いながら
fixing 1
fixing 2
とかメッセージが出ます。
多分、インデックスの定義数だけ続くと思います。
これも、多分なんですが、最初のコマンドでは、
–ft_min_word_len=3
が抜けていたので、インデックスの処理が上手くいかなかったんだと思います。
コマンド実行時にTMDファイルが残ってるよって言われたら、
TMDファイルを削除してから作業する事で対処できます。
–forceオプションを付けたら上書きするみたいだけど、自分で消してからやった方が良いです。
時間のかかる作業なので、できるだけキレイな状態でコマンドを通した方が後でダメだった時に原因の切り分けが早いです。
以上で修復は完了しましたが、CPU100%の謎は残ったままなので、色々と調べているとメモリの空き容量が少ないと出ることがあるみたい。
phpの設定で
mysql.allow_persistent = On
   ↓
mysql.allow_persistent = Off
に設定してPHPからMySQLへの持続的接続を許可する→しない
に変更しました。
これで、持続的接続が行われなくなったので少しはメモリ使用量が抑えられるハズです。
本日のデータベース復旧作業終了から数時間経過していますが、現在は調子良く動いています。
って、昨日も似たような事書いた気がする・・・また、明日もDB障害が発生するのかなぁ。
機嫌良く半年以上も動いていたのに、まさかここまでトラブルを起こすとは思ってもいませんでしたよ。
もしかすると、メモリ不足の可能性もあるので、もう少しmy.cnfの調整を行う必要があるかもしれません、明日からは、普段のくだらないブログを書けるといいな〜

追記:翌日に続く

雑談スレ

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)