こんにちわ。
今回は主に(当ブログの)mysqlデータベース復旧のお話になります。
担当のお方が
「waordpressだとinnodbよりmyisamのほうが早いらしいので、
変える前にinnodbのmy.cnfのパラメータいじくってベンチマークとろうとした」
ことをきっかけにDBのデータがぶっ壊れました。
mysql5.6ならmyisam使わなくても参照専用トランザクション使うよう改造できれば早いらしいよという話はおいといて。(5.5だし)
DBデータが読めなくてwordpressの管理画面にログインできなくなってしまいました。
-————————————————–
130528 11:59:24 [ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_current’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_history’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_history_long’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘setup_consumers’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘setup_instruments’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘setup_timers’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘performance_timers’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’threads’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_summary_by_thread_by_event_name’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_summary_by_instance’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_summary_global_by_event_name’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘file_summary_by_event_name’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘file_summary_by_instance’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘mutex_instances’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘rwlock_instances’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘cond_instances’ has the wrong structure
130528 11:59:24 [ERROR] Native table ‘performance_schema’.‘file_instances’ has the wrong structure
130528 11:59:24 [Note] Event Scheduler: Loaded 0 events
130528 11:59:24 [Note] /usr/libexec/mysqld: ready for connections.
Version: ‘5.5.30-log’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL) by Remi
130528 11:59:50 [ERROR] Cannot find or open table xxxxxx_db/dl_options from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn’t support.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.);
-————————————————–
データディレクトリに.frmファイルしかないということでしたけども、
my.cnfにinnodb_file_per_tableが入ってなかったので、たぶんibdata1とかにメタデータとかが入ってるんじゃないかなあ。
innodbのパラメータいじって起こる不整合といえばinnodb_log_file_size変えたりとか色々してるとありえそう。
詳しくはログを舐めるようにじっくりみてみないとわかりませんが。
状況：
・4月の時点でのバックアップが存在し、日次のバックアップはなし
・4月以降の更新情報は記事4つ分とユーザ追加くらいでWEBのキャッシュと記録から復旧可能
・バイナリログデータは量も少なくタイムスタンプも新しく切りまわされて消えてる風でロールフォワードリカバリは無理そう
・なくなったデータのテーブルは全てinnodbでmyisamでないのでrepair table tablename USE_FRM;とかできない
・innodb_force_recovery = 6とかしてもmysqldumpできない。
・時間もなくmysqlbinlogでバイナリログ確認とかログの詳細解析とか都度エラー検索対応とかこれ以上は工数もったいない。
ということからテーブル消して4月の時点のデータをロードしてそこからは保存したキャッシュ等で人力復旧
という方針に。(管理画面入れないので編集中だった2件さよなら。またかきます。）
やった作業： [php]ls -l /home/xxxxxx-op/xxxxxx_db.bak.sql.bz2 man bzip2 bunzip2 -c /home/xxxxxx-op/xxxxxx_db.bak.sql.bz2 > /root/xxxxxx_db.bak.sql vi /etc/my.cnf #innodb_force_recovery = 6 service mysqld restart ps -ef|grep mysql netstat -lnpt mysql -u root -p drop database xxxxxx_db; drop database performance_schema; create database xxxxxx_db; mysql -u root -p xxxxxx_db < xxxxxx_db.bak.sql[/php] それからエラーログ大丈夫そうかとサイトの表示確認を。
あとはの更新はキャッシュから復旧しておいてね的な。
今回の教訓：
慣れていない作業をする場合、とりあえずバックアップは必要でしょう。。
今回のようなユーザの少なめなブログとかですと構成はもちろんシングルなので、
バックアップは何時でもいいから日毎にとるのがよいでしょう。
(サービス用途なら接続の少ない明け方等に整合性や文字コードその他を考慮してとります)
2台以上ならオペミス対策としてのバックアップがreplicationのみというのは禁止です。
（replicationはミスも反映されてしまうため。意図的に遅延させてるreplicationは別だけどバックアップはあったほうがいいかな。）
