Hatena::ブログ(Diary)

記録日記 このページをアンテナに追加 RSSフィード

2009-07-27 mysqlでIncorrect key file for table このエントリーを含むブックマーク

時間的には1時間ぐらいだけど、心理的にはどえらいはまった。

だって、テーブルが壊れてるとか言いやがるんですから・・・。

クライアントから連絡があってメルマガの配信者リストが設定出来ません、と。

で、調べてみるとselectするSQLでこけてるようで、そのSQLを取り出してコンソールから実行してみるとタイトルのエラー。

「Incorrect key file for tableうんちゃらかんちゃら・・・」

この時、「うんちゃらかんちゃ」のところにファイル名で「/tmp/うんちゃら」ってあったんで、そこで気付ける人は気付けるんだろなぁ。

でまぁ、ぐぐる時の基本、固定文字列っぽい文字で検索してみようってことで、

Incorrect key file for tableでぐぐったら、

MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.2.4.1 MyISAM テーブルの破損

が出てきて、テーブルが破損とか出てプチ頭真っ白。

時間的にもこんな時間(問題発覚したのは21時過ぎ)だし、何が原因にしろデータが破損すれば復旧は求められるし、面倒だなって感じで。

で、↑のページにある通り「CHECK TABLE」で該当のテーブルをチェックするもステータスOKとのこと。

うーん、矛盾してやがる・・・。

エラーメッセージは「テーブル破損」、でも、チェックしても「ステータスOK」どうしたもんか。

何から調べればいいかも見当がつかなかったので、たまたまオンラインだったid:penguin_niisanに相談。

そしたら、tmp領域がいっぱいかもねと言う一言がきっかけで、急速に解決へ向かった。

df -hで容量調べたら、案の定、/tmpを含む領域が91%になっていた。

いや、確かに、今日の昼間に/rootバックアップデータ置いたけどさー、/tmpってそれだけで一個パーティション切ったりすると思ってたからさー

まさか、こんなことに繋がるなんて。

しかも、割り当てがされてないnoneが2Gあった。なんだこの謎のディスクスペースは。


まぁ、話は戻って、そのバックアップデータを消して、容量が空いたら普通にSQLも通って、万事解決しました。

てことで、Incorrect key file for tableのエラーメッセージは、必ずしもデータが壊れてる訳じゃないよと言うお話でした。


ありがとう!id:penguin_niisan

YokokawaYokokawa 2010/03/30 12:49 参考になりました!
ありがとうございます^^

fuki1234fuki1234 2010/03/30 13:26 >Yokokawaさん
参考になって良かったです!

mosimosi 2011/02/23 11:42 どんぴしゃの情報でした。ありがとうございます。

fuki1234fuki1234 2011/02/23 11:49 >mosiさん
良かったです!!

atLastatLast 2011/09/18 02:17 参考になりました。ありがとうございます!

MasaMasa 2014/01/28 10:03 2014年1月だけど、どストライクなネタに感謝です!
本当にありがとうございました♪

Connection: close