DVDのラベルを印刷しようと手元にプリンタを持ってきた。 EPSONのPM-A900である。 順調に印刷は進んでいったが、床において使っているので、横になろうを足を伸ばした拍子にプリンタを蹴ってしまった。 アチャ~、液晶
データベースが壊れた・・・
以前このホームページは自宅サーバで運用していたが、今は某社のレンタルサーバでwordpressやらpukiwikiを使って運用している。
記事を投稿しようとしたところ、wordpressのカテゴリ一覧にカテゴリが表示されていない。
(レコードの件数は表示されているが、データが表示されていない。)
おや、と思ってホームページを覗いたら一見ちゃんと表示されているような、いないような。
・・カテゴリが表示されていない。
記事単体へのリンクがあるところをクリックするとちゃんとデータは表示されるが、カテゴリへのリンクを埋め込んでいるところをクリックするとエラーになる。
どうやら、DBが壊れたみたい。
管理ツールのphpMyAdminで調べていくと、
・テーブルのデータは表示できる
・テーブルの構造を表示しようとすると「#126 – Incorrect key file for table ‘/home/tmp/*******’; try to repair it 」というエラーメッセージがでる
・テーブルによっては「#1030 – Got error 28 from storage engine」というエラーがでる
wordpressの管理画面では、全ての投稿のカテゴリが未分類になっていた。
wordpressの場合、termsというテーブルにカテゴリ名の情報を持っているが、このテーブルのデータは残っているようだった。
また、postsのテーブルもちゃんとカテゴリIDは埋まっているようだった。
phpMyAdminで、テーブルのチェック(CHECK TABLE `xxxx`)と修復(REPAIR TABLE `xxxx`)を試すが、SQLはOKを戻すが 「Incorrect key file for table 」等のエラーは消えずwordpressでもカテゴリは見えない。
・・CHECK TABLEは、DBがMyISAM、InnoDB共に使用できるSQL文ですが、REPAIR TABLE は、DBがMyISAMのときだけのようです。念のため。
google先生に聞くと、「Got error 28」等は/home/tmp等の領域不足ででるようなこともあるそうな。
ただ、レンタルコースのお安いコースでは権限が無く見ることができない。
ちょっと時間がたったバックアップしかもっていないので、全てバックアップできるか不安だったが、あわよくばという気持ちでバックアップをとってサポートに電話で相談してみた。
案の定、「ハード的に問題は無いので、DBの内容についてはお客様の自己責任で」という回答。
そうですか。
一応、「telnetで操作できる範囲なら何やってもいいんですか?」と聞いてみたら「ちがう部署が回答するのでメールで問い合わせて」とのこと。
ウ~ム、普通メールのやりとりでらちがあかないから電話するんじゃ・・と思いつつメールに向かう。
で、本日。
まだサポートから回答はないので、ひとまず対処方法を考えてみる。
■DBを作り直したら、本当に動くのか?
試しに新しいテーブルを作成してみたが、テーブルは作成されるものの、「Incorrect key file for table 」のエラーメッセージもおまけについてくる始末。
これじゃぁ、DBの作り直しだけじゃ対応できない。
まぁ、ここらがレンタルサーバのお安いコースの限界と悟る。
商用サイトを運用するなら、もうちょっとサポートの厚いコースか権限のあるvirtualサーバなどのコースが必要ということですかねぇ。
じゃぁ、このサイトは閉鎖か?
というものねぇ。
で、ふと気が付いた。
このレンタルサーバのコースは昔1つのDBだけした使えなかったが、その後複数のDBが作成できるように変更になっている。しかも、その際の移行の流れだと思うが、DBサーバが2つに分かれたようだ。
このホームページは古いDBサーバにデータをおいているので、新しいDBサーバにDBを作ることにしてみた。
DBを作成して、古いDBからエキスポートしたテーブル類を新しいDBにインポート。
DBの接続設定を変更して完了。
ちゃんと、カテゴリも表示されるようになった。データは破損していなかったようだ。
?? そこまでして修復するようなホームページかって ??
まぁ、趣味ですから・・
■教訓
・DBと設定ファイル類のバックアップはこまめにとりましょう。
・商用などの止めては困るサイトはちょっとコストがかかってもサポートの厚いコースにしましょう。
・お安いコースでいくなら、2つのコースを契約して、1日分のデータ消失はあきらめるとして日々相手側にバックアップをとって障害に備えるのも手か?
って、ところでしょうか。
結局、Mysqlのエラーの原因は未だ不明。
■本来なら
・MySQLが使用するテンポラリ領域の空きの有無の確認
・MySQLの再起動
等を行って原因調査や確認ってところでしょうが、手が出せないレンタルサーバではここまで。