WordPressで作るアンテナサイトのDatabase障害に立ち向かう冒険

前回までに基本的な機能の実装が済んだので、周辺環境のメンテナンスの一環としてデータベースのお手入れの話をちょこっとはさんでおこうと思う。

WordPressで使うデータベースはMySQLなわけだが、これが知らぬ間に結構な頻度でデータの出し入れをしており、メンテナンスしてあげないと障害を起こしてしまうのだ。管理画面に突然ログインできなくなったりする。そんな状況に直面し、全くメンテナンスなど気にしていなかったと言う場合には、テーブルの最適化をしてあげると直る事がある。WordPressのデータベースには、次のようなテーブルがある。

mysql> show tables; 
         
+-----------------------+
| Tables_in_unkodb      |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_ktaisession        |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
12 rows in set (0.00 sec)

mysql>

この内、wp_posts がwp_postのコマンドで投稿した物が格納されており、?wp_term_relationships　でその投稿がどのカテゴリーに所属しているか、どのタグが付いているかの情報を格納している。それに加えてwp_postmetaの３つのテーブルが激しく更新されるので、ゴミがたまってしまう。その為、定期的に最適化してあげないと、パフォーマンスが著しく低下したり、アクセスできなくなってしまったりする。なので、以下のコマンドをcron等に登録し定期実行するといい。

mysqlcheck -u ユーザ名 -pパスワード --auto-repair --optimize -A -h 'データベースのIP' > 実行結果のログファイル 2>&1 

チェックして、オプティマイズし、オートリペアーしている。実行結果なんていらねえよ、夏 という方は、リダイレクトを最後の捨てちゃうリダイレクトだけ残しておけばいいだろう。

しかし、これだけでも駄目な時がある。それが今日だ。現在、我がKnowledgeアンテナ研究室は御覧の通りＤＢ障害のため閉鎖中である。どうやらselect文は投げられるのだが、テーブルに対してdescなど投げたら、こんなエラーが返ってくる。

ERROR 126 (HY000): Incorrect key file for table ‘ほにゃらら.MYI’; try to repair it

調べて見たら、mysqlのマニュアルでは、リペアすると直るよって書いてある。しかし、マニュアル通りに、checkしてみても、repairしてみても、ＯＫと出るだけで一向に症状が直らない。さらに問題を掘り下げようにも、今使っているさくらインターネットのプランは共有サーバなので、自分のホームディレクトリ以外はいじくれないのだ。mysqlのログすら見れない。借り住まいの苦しい所である。さらに、さくらインターネットではmysqlはサポート対象外なのだ。自分で問題解析するほかないのだが、ログすら見れない。暫くグーグル先生にしつこく聞いてみると、どうやらtmpディレクトリにアクセスできなくなっている場合に、各コマンドはＯＫだが、エラーを吐き続けると言う症状に陥るらしいと言う声がちらほら拾えた。

MYSQLでIncorrect key file for table → check tableしてもOKな場合の対処方法
2009-07-27 mysqlでIncorrect key file for table?

多分原因はこれだろう。これじゃなかったとしてもこれ以上私にはわからない。とりあえず、さくらインターネットのサポートにメールを投げて置いた。日曜は休みだそうだ。私のＨＰは今日は障害を伝えるトップページに置き換えるのがやっとやっとである。これで今日一日まるまる潰れてしまった。このブログでさくらインターネットの話題を出すので、広告を貼り付けようと、広告を申し込んだのだが、断られてしまったのは、こうして文句ばかり書くからだろうかと、ちょっとやさぐれ気味になってしまった。やはり高いプランに入らなければ、こういう障害は日常茶飯事だと言う事なのだろう。やすかろう、わるかろうである。
ともあれ、今回のＤＢ障害で、データベースに蓄積していた情報の半分以上がぶっ飛んでしまった。これまで皆さんが張ってくれたリンクに、大量の４０４NOT FOUNDを返さねばならぬ事が、悔しくてならない。とくよくよしてばかりもいられない。データベースのバックアップの仕組みを実装していなかった私も悪いのだ。バックアップしていれば今頃は私も余裕でワインを傾けながら、さくらインターネットからの回答を笑顔で待つ事が出来ていただろう。今私がなすべきは、ネガティブな言葉を並び立てる事では無く、ＤＢの定期バックアップのシェルを組む事なのだ！と思い直し、下記のようなシェルを書いてみた。

#!/bin/sh

cd /unko/unko/

dump_list=`ls -tr ./backup/dbdump_*`
list_ct=`ls -tr ./backup/dbdump_* | wc -l`

if [ $list_ct -gt 2 ]; then
   loop_times=`expr $list_ct - 2`
   loop_cn=0

  for i in $dump_list
    do
        if  [ $loop_cn -ne $loop_times ]; then   
           rm $i
           loop_cn=$(($loop_cn+1)) 
        else
           break
       fi
   done
fi

mysqldump -u 'ユーザー名' -pパスワード -h ホストIP 'DB名' | gzip > ./backup/dbdump_`date +%Y%m%d-%H%M%S`.gz
rt=`echo $?`

if [ $rt -ne 0 ]; then
    echo "`date` データベースのバックアップに失敗しました。リターンコード $rt"  > ./logs/db_backup.log
else
    echo "`date` データベースのバックアップに成功しました。リターンコード $rt"  > ./logs/db_backup.log
fi

exit $rt

今のモチベーションではこのクオリティーが限界である。これを一日一回流せば3世代補完のDBバックアップの出来上がりだ。一日前であれば、RSSからリンクを取得しなおしても元の状態までは復帰できるだろう。オブジェクトＩＤがずれてしまう事は仕方がない。差し当たっての復旧が第一である。これで次からは優雅にさくらインターネットのサポートセンターとやり取りが出来るだろう。私にもっとお金があれば KAGOYAのシェルログインできるプランに乗り換えてやるものを。貧すれば鈍す。お金が無いのは悲しい事だ。

未だ復旧の見込みは立っていないが、再発防止が出来ないなら、再発してもいい体制は整えて置くと言う方針で、対処が出来たと言う事にしたいと思う。次回からはRSS出力用の投稿の為のカスタム投稿の追加（ポストタイプの追加）などに付いて言及したいが、それはＨＰが復旧してからにした方が良いのかもしれない。

＊追記：　反響にお答えし、アンテナサイト用Wordpressテーマ「Antena Institute」をリリースいたしました。
詳しくは、「Antena Instituteについて」をご参照ください。
ご購入を希望される方は、下記リンクにてAntena Instituteをご購入ください。