MySQL Casual Talks vol.6 で N:1レプリケーション 書き換えについて話してきたこと
去る 2014年07月11日、MySQL Casual Talks vol.6 が開催され、例のごとく LT してきました。
ちとごたごたして書いてなかったので、今更だけど書き綴る。
MySQL Casual Talks vol.6 の自分以外のトークについては @namikawa さんがまとめられているので、そちらを参考に → 「MySQL Casual Talks vol.6」に参加してきた＆資料まとめ #mysqlcasual - 元RX-7乗りの適当な日々
マスタN対スレーブ1 レプリケーションの課題
毎度飽きずに、異なるデータセットを持つ複数台のマスタDB から 1台のスレーブDB をつくる手法、通称 "N:1 レプリケーション" のトークをしています。
3年前に N:1 レプリケーションを実装してから今までホントに安定して動き続けていて、今この記事を書いている (そしてあなたが読んでいる) この瞬間にも、2秒に1回レプリケーション対象のマスタサーバを切り替えているのですが、さすがにこれだけの期間使っていると課題もあります。
例えば、MHA による マスタDB のスイッチが発生した場合に追随する手段がないことは前からどうにかしないとなぁと思いつつ、頻繁に発生することでもないし、その時対応すればいいかなぁなんて感じで、はぐらかしていた課題でもあります。
ただ、実を言えば、自分の中で最も大きい課題は、 N:1 レプリケーションを動かすコードにテストがないことでした。
コードの書き換え
そんなわけで、もともと SwitchMaster という名前で公開していたコードに手を入れることに。
まず最初にしたのは、テストを実行するための環境作り。
ほとんど1ファイルにベタに記述されていた実装を、 SwitchMaster package として切り出し、もとのファイルはその package を呼び出すだけにしました。
その後、perl には minila という、CPAN モジュール開発支援ツールがあるので、これをつかって、テストをしやすい環境を構築しました。
これで、元々のコードに対して、テストコードがかけます。
あとは、テストを壊さないようにモジュール分離を進めつつ、テストコードを健全にしていくだけでした。
MHA 対応を図った副作用
ただ、このあたりで MHA 対応できないかなー という悪魔の誘惑が。
現在のところ、(スライドにもあるとおり) MHA によるマスタスイッチに自動的に追随することはできませんが、ちこっと MHA を書き換えれば何とかなるハズ。少なくとも graceful master switch に関しては、master_ip_online_change_script への引数にオリジナルマスタのbinlog 情報と新マスタのbinlog 情報があればどうにかなるのですよ。
ま、とはいえなるべく MHA に手を入れることなくどうにかしたいので、何か別の手段を考えています。出来るのか分からないけど。
んでこのあたりで気づいてしまったことがもう一つ。 MHA によるマスタサーバの入れ替えって、 master switch と呼ばれているのですよ。
元々、自分が書いていたコードは SwitchMaster。 なんだか紛らわしい。
ということで、名前を SwitchMaster から N1Repl に変えました。
(リポジトリ名も変えちゃったけど、fork もされてないようなコードだったしいいよね)
N1Repl
コードは https://github.com/do-aki/N1Repl にありますので、もし良ければ見てやってください。
そして、酷いと感じたコードについては指摘してやってください。
それと、スライドの英語についてもおかしな記述があったなら指摘もらえると助かります。
