私用で駆け回る前回の土曜。LINEに連絡が入っているのに気がついた。

「お客さんがWordPressにログインできない。」

本当にその一言だけ。

 

どうログインできないのかなどは書いてなかったため、そもそもログイン情報に関するログイン失敗なのか、ログインそのものはできているがそこから先に進めないのか。

全く、状況が読み取れない。

 

俺が事前に知っていた情報としては、そのWordPressは共用サーバー上で動いており、普通に運用する上ではログインできなくなるといった状況はあまり考えられないということ。

今回は実際の作業にあたり、デバッグモードをONにした際にGot error 28 from storage engineでWordPressにログインができないのを対処した話を書こうと思う。

 

で、件のLINEに対して、(ﾟДﾟ;)ﾊｧ?とリアルでそんな顔になりながらも連絡を取ってみた。

どうも、その人によってすでに調査は始めていたらしいが、いまいち自分で実際に見てみないことには皆目見当もつかない。

 

まぁ連絡を取る前に予想されているものとしては、Cookieのゴミデータが残っているからだとか、そもそもログイン情報が何らかの形で書き換わってしまっているかなどと予め要因として考えられるものを思い浮かべていたが・・・。

 

今は便利な時代で、単に「WordPressにログインできない」と調べれば、原因として考えられるものがいろいろ出てくる。その人は場当たり的にそれらを試して対応にあたっていたようだ。

（普段コードを書いていたり仕様設計をしている多数の人間からしたら息を呑むようなやり方ではある。）

 

それはさておき、まずサーバー情報をもらった後、すぐ一番にデバッグモードをONに。

・・・なぜ最初に調査を始めた者がまずデバッグモードをONにしていないかというツッコミは勘弁してほしい。

営業兼デザイナーさんだからしょうがないことなんだ(´・ω・｀)

 

で、まぁデバッグモードをONにしてみると、「Got error 28 from storage engine」のエラーが出てきた。

件のエラーに合わせて、いたるところに「SELECT * FROM TABLE」や「SHOW FULL COLUMNS TABLE」でのSQLエラーが検出されている。

これも言葉通り、もしくは、ネットでまず引っかかるものをそのまま鵜呑みにするのであれば、MySQLサーバーの容量エラー。

 

ところが、お客さんの環境は共用サーバーであり、MySQLも別途のデータベースサーバーで管理されているはずなので、俺はこれは言葉どおりの意味ではないのはすぐに感づいた。

 

共用サーバーで、VPSだとか独自サーバーで出るような容量の表示がなされるかはわからなかったが、連絡をしてきた人がネットに書いてある情報を掘り出している間にも、SSHに入ってdfコマンドをいの一番に叩いてとりあえずのところのサーバーの容量を確認している。

まぁ当然、容量がオーバーしている、な～んていうことはもちろんのことない。

 

そのまま連絡してきた人と一緒に調査を進めたが、ネットの情報をそのまま場あたりしていくだけの方法に付き合っていては一向に進展がしないし、昼一の私用のほうもまだ残っていたので、一度調査を中断した。

 

 

で、少し飛んで、一人で調査を再開したのは夕方頃。

この頃になると、俺には別の疑念が思い浮かんでいた。

 

その疑念を確かめるため、調査再開一番でお客さん環境のテーブルのダンプを引っこ抜いて、自分の開発環境へ突っ込んでみた。

 

んん？？？

 

ふつうにログインできて動かせるやんけ。

 

そこで、思い浮かんでいた疑念が確信に変わるのを感じた。

 

そこでお客さんのサーバーに戻り、MySQLのスキーマをそっと見てみた。

 

はい。

 

案の定、データベースぶっこわれてました＼(^o^)／

 

本来あるはずのものがなくなっていたりの設定がなくなっていたり、スキーマのテーブルが一部吹っ飛んでいたり、もうなんかすごいじょうたい(^q^)

 

まぁ共用サーバーで使うWordPress用のデータベースがぶっ壊れる要因としてはいろいろあると思う。

スキーマの書き換えを伴うプラグインがその書き換えに失敗したり、データベースの書き込みが入る際に変なタイミングで処理を中断したり、もしくはアップデートなどを行っている際にサーバー負荷の関係で処理がすっ飛ばされたり、どっちかのサーバーが一時的・断続的に止まるかとかで中途半端に処理された場合とかとか。上げはじめるとキリがない。

 

ただ一つ言えるのは日々の更新の中で数ある要因のいずれかひっかかったという不幸な出来事。

まぁWPのテーブルがまともに残っていたのは不幸中の幸いだろうか。

 

件の「Got error 28 from storage engine」がなぜ出てきたかというと、

1. 前述のような要因でスキーマがぶっこわれる。
2. にも関わらず、SHOWなりSELECTなりのクエリが発行される。
3. 構成要素が中途半端なので、正常にクエリが発行できず、極限無限に結果を返そうとする。
4. クエリがストレージの容量から溢れてメモリエラー

さしあたり、大方のシナリオはこんなところだろう。

 

なんにしてもスキーマがぶっ壊れている以上どうしようもない。

 

開発環境へテーブルを突っ込んだときよろしく、元のデータベースとは別のデータベースを立てて、ダンプを突っ込んで最後にWordPressの動作確認だけして終了。

 

ちなみに、ぶっこわれたデータベースを操作するときは正直冷や汗モノだった。

 

なんでって、これさ。

 

ぶっちゃけ、うちのブログ・・・つまり、このクソコーダーのクソみたいなブログのデータベースが今年の3月に吹っ飛んだときの状況と酷似してるんだよね。

※データベースが逝って、ブログのデータが全て消し飛んだを参照。

 

元のデータベースを仮に復旧できたとしてもアップデート時にどうなっていたかと思うと・・・。あーこわいこわい。

まぁ自爆するのもアレだし、対処っちゃ対処だが今回の場合は最善策だったと思う。

 

過去の失敗は未来に生かさなくちゃね(´・ω・｀)