Colorkrew Blog

※古い記事ですのでご注意ください※
こんにちは。小宮です。

社内のMyISAMテーブルが混在しているサービスにて、
mysqldumpによるバックアップに失敗しコールドバックアップを取ったが不整合出たという事件について相談うけまして、
その顛末を記録しがてら注意事項をまとめておきたいと思います。
　（昔軽く伝えた記憶があり皆知ってると思ってたんですが、わかりやすさや伝える力と、
　私と他の人のmysqlに対する愛のレベルが少し異なるという認識が足らなかったようです。
　トラブルは起きるもんだし失敗は挑戦の証で成功の元ですが同じことは繰り返さないようにしないと。）

何が大切かって、マスタとスレーブのデータの整合性です。
　つまり、
　⇒バックアップ対象が絶対に更新されてないこと
　⇒バックアップ取得時点のポジションとバイナリログファイル名が明確であること
　が超重要です。
　MyISAM混在環境では気をつけないと不整合でます。
　不整合でると購入したはずのコンテンツが買われてないように見えるなど割と大変なことになりますね。
　InnoDBだけなら–single-transactionつけとけば不整合は気にしなくて大丈夫です。

・mysqldumpに失敗した原因

mysqldump: Error 1317: Query execution was interrupted when dumping table

このエラーは、
mysqldumpでデータを読んでる間にクエリーが中断されると出るやつです。Ctrl + Cとかkillでスレッドが殺されたとか。。
（とTwitterで教えていただきました。ありがとうございます。

それから、整合性のためにマスタからmysqldumpでデータをとることになったのですが、
その際にslaveでreplicationを止めて更新がない状態でとっている方法をそのまま用いたのも不整合が起きる原因になりました。
（MyISAMが混在する環境なのにFLUSH TABLES WITH READ LOCK;をしてなかった）

MyISAMが混在する環境の場合、トランザクションは使えないので、
replicaion停止または共有ロックで更新停止が必要になります。

ex)
FLUSH TABLES WITH READ LOCK;
sleepやsyncでロックが終わる(確実に更新停止される)のを待つ
ポジションとファイル名をとりログに記録する
mysqldumpする
UNLOCK TABLES;

特にクエリを中断したりしてない(中断と整合性がごっちゃ)という指摘があったりしてそれは私もよくわからないところですが、
更新されないようにしてれば中断も起きるはずがないので、対処方法は更新を確実に止める一択かと思います。