実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ)

mysql

レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。

埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。
http://www.irori.org/pub/mysql-mm.mov

登場するホスト

登場するホストは2台、db901とdb902です。
最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。

画面分割

画面は5分割しています。

  • 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ
  • 右上 = ping -n db900
  • 右下の2つ = 上のが ping -n db901、下のが ping -n db902
  • 左下 = db901を落とそうと待ち構えているターミナル

動画の解説

00:00
はじまりはじまり。db900に対するselect、db900,db901,db902に対するping、すべて正常に流れている。selectのserver_idは、db901のものである「901」が返ってきているのを覚えておいてください。
00:11
この時点でのプライマリでもあるdb901を強制終了する。強制終了には SysRq を使ってバルスっと落とす (# echo b > /proc/sysrq-trigger)
00:12
db901が停止したので、db901に対するpingがとまる。db901はdb900でもあったので、db900に対するpingとdb900に対するselectも止まる。
00:17
首尾よくフェイルオーバが完了し、db902がdb900となったので、db900に対するpingとdb900に対するselectが回復(server_idが「901」から「902」に変わっている点に注目！)した。yay!

フェイルオーバのメカニズム

今回のケースでは、停止から 5 秒後には、

  • 異常の検知
  • プライマリのフェイルオーバ

が完了しています。

フェイルオーバのメカニズムは、レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン の 「<セカンダリをプライマリに昇格>」に書いた通りなんですが、監視とこのフェイルオーバ処理の実装は、

で行ってます。

あとがき

これでお正月は安心しておもちがたべられそうです ＾ρ＾