この記事は animateLAB Advent Calendar 2015 12日目の記事です。
ということで12月12日を迎えました。本日は私の誕生日です。おめでとうございます。ありがとうございます。
誕生日といえばなんとなくAmazonのウィッシュリストを貼ってなんとなく送りあう文化がありますが、さすがにこの記事に貼るのはやめておきます。誕生日といえば、MySQLです。
数年前の誕生日のこと、0時を過ぎて誕生日になり、SNSにウェーイって感じでウィッシュリストのURLを貼りながら、とあるサイトがメンテナンス表示になったのを確認して寝ました。その日は、サーバーの老朽化に伴い別サーバーへの移行が行われる日だったのです。
サーバーの移行って、新サーバーに引っ越し終われば（DNSの切り替えが済めば）完了でしょうか？たいていの場合はそのようなことはなく、引っ越し終わってからがお祭りの始まりです。
翌朝、出社してから報告があった主な出来事は次のようなものでした。
- なんかたまにエラーがでる
- なんかたまに文字化けしてる
「なんかたまにエラーがでる」はDNS切り替え手順にまつわる話であんまり大したことはないので置いておくとして、厄介なのは「なんかたまに文字化けしてる」のほうです。文字化け自体厄介なのに「たまに」って何だよって話です。
とにかく文字化けしたデータをなんとかしなくてはなりませんので、「なんかたまにエラーがでる」をなんとか夕方ぐらいまでに潰し、文字化けの調査・検証を本格的に始めようとしたときにそれは起きました。
な ん か デ ー タ が 消 え て い く
さすがに目を疑いました。全く同じ結果が返ってくるはずのSELECT文を何回か投げると毎回結果が減っていくのです。恐怖しかありません。
仕方ないので、サイトを閉鎖し本格的に原因調査が始まりました。結論から言うと原因は以下のようなものでした。
- 文字化けの原因：データ移行作業中に行ったMySQLのデータインポート時に、"default charset"の指定が足りない箇所があった
- データが消えていく原因：とある作業者が文字化けの検証のためにデータダンプを別のdatabase指定でデータインポートをしようとしたところ、誤って本番のdatabaseに上書きしてしまった
文字化けが発生したのは、MySQLのdatabaseやtableにdefault charsetを指定していなかっため,tableの文字コードはlatin1なのに実データはutf8みたいなミスマッチが起こってしまったためです。しかもアプリケーションとのJDBC接続においてutf8かどうか明示的に指定してたりしてなかったりしたため、「たまに文字化けする」という事象につながった記憶があります。
このような事象はMySQLのテーブル作成がカッチリとutf8で行われていれば発生しませんでしたので、単に指定漏れですね。
問題なのは後者です。たまに本番作業をしていると「このコマンドミスったら本番のdatabase上書きだなー怖いな－」といった場面に出くわすことがありますけど、本当に上書きされてしまった現場に遭遇するとは思いませんでした。
どうする折部やすな。
明日へ続く！！
