MHAの次を目指す mikasafabric for MySQL

MHAの次を目指すmikasafabric
for MySQL
今年のアドベントカレンダー
2016/11/05
yoku0825
OSC 2016 Tokyo/Fall

＼こんにちは／
yoku0825＠とある企業のDBA
オラクれない-
ポスグれない-
マイエスキューエる-
家に帰ると
妻の夫-
せがれの⽗-
ムスメの⽗-
⽣息域
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
MySQL Casualʼs Slack: MySQL Casual-
1/73

mikasafabric for MySQL #とは
GMO Media, Inc.によってメンテナンスされている
MySQL Fabric のフォークプロダクト
MySQLの障害を検知してマスターの⾃動切換え
MHA for MySQLと同じポジションを担うフレームワーク
2/73

Do you know
MySQL
Fabric ︖
3/73

MySQL Fabric #とは
⾼可⽤性（High Availability）
障害探知と昇格-
データベースリクエストのアクセス先の選択-
シャーディング – スケールアウト
MySQL Fabric – コネクタとの連携
プロキシ不要の構成-
MySQL :: MySQL Fabric
4/73

MySQL Fabricを導⼊した構成
AP
[Not supported by viewer] Connector/J
Master Slave
mysqlfabric
Monitor/Demote
Monitor/Promote
Lookup Group Query
Routing
Routing
AP
AP Connector/J
5/73

MySQL Fabric構成の仕組み
MySQL Fabrci対応コネクター（図中ではConnector/J）が
mysqlfabric デーモンからHAグループ情報とシャードグル
ープ情報を受け取る
Connector/J 以外では Connector/.NET, Connector/Python-
アプリケーションはMySQLの代わりに mysqlfabric のデー
モンに接続する（IPアドレス, ポート）ような設定にする
すると、Connector/Jがその接続をハンドルして、HAグループのマス
ター/スレーブ, シャードの属するシャードグループにプロキシーして
くれる
-
mysqlfabric デーモンがダウンしている場合、直前のキャッシュを使
ってルーティングする
-
HAグループ内のフェイルオーバー処理、シャードグループ
間のリシャードは mysqlfabric デーモンのAPIを介して⾏う 6/73

つまり
MHA for MySQL と同等の使い⽅が可能
MHA for MySQL はWEB界隈で最も⼈気の⾼いMySQL冗⻑化ソリ
ューション
ダウン検出でマスターの⾃動昇格は⽋損しているバイナリーログの（可能な限りの）
リカバリーを含み
昇格時にキックされるスクリプトでVIPやDNSの書き換えを⾏う
-
GTID必須（MySQL 5.7のオンラインGTID有効化で⼀気に
⾝近に）
クラッシュセーフスレーブの設定でも使える
MHA for MySQLは relay_log_info_repository= TABLE と相性が悪
くて起動に転ける
-
7/73

MHA for MySQLとの⽐較
MHA for MySQL MySQL Fabric
マネージャプロセス masterha̲manager mysqlfabric
マネージャの状態確認ログのみ mysqlfabricコマンド (デー
モンと同じコマンド)
エージェントライブラリなし
切り替わり時のリカバリー⼀番進んでいるスレーブのリ
レーログから(via SSH)
なし
切り替わりの処理 master̲ip̲failover̲script ファブリック対応コネクター
依存
処理フック master̲ip̲failover̲scrip
t,
secondary̲check̲script,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
SERVER̲DEMOTEDが予約
されているが、Pythonで直
書き
構成の検出⾃動⼿動で登録
サーバーの追加, 削除コンフィグ編集, 再起動 mysqlfabricコマンド
8/73

なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
9/73

マネージャプロセス
どちらもMySQLと別のプロセスが切り替える
OSダウンを考えると別のノードに収容しておきたい-
スレーブだけ単体でOSごと落ちるのであれば切り替わり⾃体は必要な
いので2台3台構成ならそれも⼿ではあるが
-
マネージャプロセスのダウンは切り替わりができないだけ
で、サービスそのものに影響は出ない
10/73

マネージャの状態確認ログのみ mysqlfabricコマンド (デ
ーモンと同じコマンド)
なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
11/73

マネージャの状態確認
MHA for MySQLはプロセスの内部にマスター/スレーブの情
報を持ち、APIは特に⽤意されていない
masterha_master_monitor はマネージャから情報を惹くのではなく、
⾃分が起動してMySQLの状態をチェックする
-
MySQL Fabricは、管理対象とは別のMySQL（バッキングス
トア）に構成情報を保存する
mysqlfabricデーモンがMySQLプロトコルとXMLRPCプロトコルで
APIを持っている
-
バッキングストアが落ちるとmysqlfabricデーモンが落ち…てくれず
に刺さる
-
12/73

なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
13/73

エージェント
MHA for MySQLのエージェントは常駐型ではない
いくつかのコマンドを提供する mha4mysql-node をインストールする-
mha4mysql-node の提供するコマンドをSSH経由でマネージャーが叩く-
MySQL Fabricはフェイルオーバーなどに必要な全ての動作
をSQLだけで実装しているためエージェントが要らない
拡張する場合はSQLでできることをやらせないといけない-
14/73

なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
15/73

切り替わり時のリカバリー
MHA for MySQLは⼀番進んでいるスレーブのリレーログを
チェックして差分を読み込み、実⾏させる
ポジションを判定してseek(), read() で読む-
MySQL Fabricは⼀番進んでいるスレーブを次のマスターに
選ぶものの、リカバリー処理⾃体は存在しない
受け取ったリレーログをすべて適⽤するまで待つだけ-
Semisyncレプリケーション必須-
16/73

なし
切り替わりの処理 master̲ip̲failover̲scr
ipt
ファブリック対応コネクター
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
17/73

切り替わりの処理（主にIPのつけかえ）
MHA for MySQLは master_ip_failover_script に切り替わ
りの処理を書く
VIPの付け替えだったり、DNSの更新だったり-
read_only の設定変更だったり、新しいレプリケーションユーザーを
作ったりの処理もここに書くことができる
-
MySQL Fabricは切り替わりはコネクターが吸収する
バッキングストアに持っているマスター/スレーブの状態を更新し、-
ファブリック対応コネクターが次にHAグループ情報を参照してきた時
にコネクター側に反映される
-
MySQL RouterもFabric対応コネクターと⾒做せる-
デフォルトのTTLは1秒-
18/73

なし
依存
処理フック master̲ip̲failover̲scr
ipt,
secondary̲check̲scrip
t, shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
SERVER̲DEMOTEDが予
約されているが、Pythonで
直書き
19/73

処理フック
MHA for MySQLはいい感じのところにフックがあり、それ
ぞれ⾃分の好きなスクリプトで書けば良い
これにより、応答がなくなった旧マスターをOSごとシャットダウンす
る、という荒業も可能に
-
MySQL Fabricもイベントトリガーは予約されているもの
の、設定ファイルではどうにもならない
更に、SSHも利⽤できるMHAに対してMySQL FabricはSSHのセット
アップを要求しないので、出来ることは限られている
-
とはいえ単にスクリプトを叩くようにイベントを書けばいいはず-
20/73

なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
21/73

構成の検出
MHA for MySQLは管理対象のIP, portをコンフィグから読
み取り、実際にどのMySQLがマスターになっているかは⾃
動で検出する
MySQL Fabricはバッキングストアの情報を正として、実態
はチェックしない
再起動には強い-
バッキングストアの内容と実態がズレると地獄が⾒える-
既存のレプリケーション環境に導⼊しようと思うとちょっとだけコツ
が必要
-
22/73

なし
依存
t,
shutdown̲script,
report̲script
SERVER̲LOST,
SERVER̲PROMOTED,
書き
23/73

サーバーの追加, 削除
MHA for MySQLは追加, 削除時にコンフィグの再読み込み
が必要
MySQL Fabricは mysqlfabric group add, mysqlfabric
group remove コマンドで動的に追加, 削除
どちらにせよこれらマネージャプロセスは単⼀障害点ではないので、
再起動でもオンラインでもそれほど違いはない
-
24/73

ここまでのまとめ
MySQL FabricはMHA for MySQLのようにMySQLの⾃動/⼿
動フェイルオーバーをサポートするためのプロダクト
MySQL Fabricは状態をバッキングストアに保管し、APIを
提供するウェブアプリケーションライクなつくり
良くも悪くも-
MHAは非同期レプリケーションしかない時代に開発された
もののため、リレーログから差分をリカバリーする機能がつ
いている
MySQL 5.7とそれ以降でサポートされた複数台の準同期レプリケーシ
ョンを利⽤すればリカバリーは不要になった
-
25/73

興味が湧いて
きましたか︖
[はい/Yes]
26/73

2016年現在の
MySQL Fabric
のGAバージョン
27/73

MySQL Fabricのパッケージング
MySQL Fabric 1.4
MySQL Utilities 1.4に同梱
MySQL Fabric 1.5
MySQL Utilities 1.5に同梱
MySQL Fabric 1.6
MySQL Fabric 1.6としてリリースされる予定
29/73

MySQL Utilities 1.6はリリース済み
MySQL Utilities 1.6.4 (2016/08/05 GA)
MySQL Fabricは1.6系から別パッケージになる予定なの
で、もうMySQL Fabricは同梱されていない
http://dev.mysql.com/downloads/utilities/
30/73

MySQL Fabric 1.6はどこにもない
以前はLab版があったが2016/11/05現在Labにも存在しない
http://dev.mysql.com/downloads/fabric/
31/73

追い打ち
http://www.slideshare.net/mattalord/mysql-high-
availability-innodb-clusters
32/73

今までMySQL
Fabricがいたとこ
ろにMySQL Shell
ガイル
33/73

先が無いことを⾒抜くのは難しい (c)matsunobu
「先が無い」とは誰も⾔ってくれない
興味の無いものに対してわざわざ情報発信してベンダー
に喧嘩を売る動機は無い
..
先が無い技術を選んで⼀番痛い目を⾒るのはその採⽤企
業とエンジニア
http://www.slideshare.net/matsunobu/ss-28303485/31
35/73

諦めますか︖
[No/否]
36/73

というよりは最初から諦めていた
MySQL Fabricつらい
MySQL Fabricつらい Advent Calendar 2014
MySQL Fabric＆Routerつらくない Advent Calendar 2015
MySQL Fabricでぼっこぼこにされたはなし
37/73

これなんかひどい
MySQL Fabric uses wrong argument of MAKETIME
in prune̲log and prune̲error̲log events.
MAKETIME functionʼs arguments are (hour,
minute, second) but MySQL Fabric passes
prune̲time as hour
mysql> DELETE FROM log WHERE TIMEDIFF(UTC_TIMESTAMP(), reported)
> MAKETIME(3600,0,0);
Query OK, 0 rows affected, 1 warning (0.03 sec)
Warning (Code 1292): Truncated incorrect time value: '3600:00:00'
MySQL Bugs: #81557: MySQL Fabric uses wrong
argument of MAKETIME in prune̲log Event
38/73

これもひどい
status compares (not equal) with string ʻFAULTYʼ
but status has integer datatype.
mysql> SELECT server_uuid, group_id, server_address, mode, statu
s, weight FROM servers WHERE group_id LIKE '%%' AND group_id IS N
OT NULL AND status != 'FAULTY' ORDER BY group_id, server_addres
s, server_uuid;
2 rows in set, 1 warning (0.00 sec)
Warning (Code 1292): Truncated incorrect DOUBLE value: 'FAULTY'
MySQL Bugs: #81559: Incorrect WHERE clause in
dump̲servers fanction
39/73

作ったやつ出てこい
もともと何故誰も⽂句を⾔わないのか不思議なレベルの品質
パッチを送っても放置
ついにはバグレポートがトリアージすらされなくなった
使ってないソフトウェアに⽂句を⾔う⼈はいない
40/73

だいぶ考えたこと
MHA for MySQLは流⾏っている
とはいえ⾃分で使うのに⾜りない機能があって
relay_log_info_repository= TABLE の場合起動できない
MHA for MySQL⾃体を監視する⼿段が微妙
あんまりメンテナンスされてる気配がない
-
MySQL Fabricだって考え⽅⾃体は間違っていなかったはず
だ
死活監視とマスター切り替えを備えたフレームワークという⽅向性-
死活監視がちょっとイケてなくて、エラーハンドルがイケてなくて、
補助機能が貧弱すぎて、ログ機構が極悪なだけ
-
シャーディングのことは忘れることにする-
41/73

オレオレパッ
チしたことあ
る⼈︖
42/73

オレオレパッチの
ソフトウェアを運
⽤したことある
⼈︖
43/73

オレオレパッチの運⽤
メインラインのバージョン固定してパッチしてビルドしては
いおしまい、なら楽
ex. mysql コマンドラインクライアント, mysqldump なんかはバージョ
ンアップしたところでそんなに機能が変わらないから、バージョンを
固定してビルドするのは⼗分現実的
-
メインラインが⽣きていて新機能が追加され続ける場合、追
従しないといけない
メインラインが別の実装で同じ機能を作ったり-
非互換のAPI変更があったり-
テスト書くのつらい-
45/73

半年くらい悩んだ結果
あまりにもつらかったので、おとなしくフォークして⾃
前でパッチを当てることにしました。フォークするつい
でに名前を変えたのが mikasafabric for MySQLになり
ます。
期待通りに使えるMySQL Fabricを目指した結果なの
で、まあまあ期待通りに動きます
mikasafabric for MySQLをオープンソースライセンスで公
開しました | GMOメディアエンジニアブログ
46/73

悩んだ経緯
というか、 “Support MySQL 5.7” と銘打たれたコミッ
トがひどすぎて、テストすら通らない（何故マージされ
たし）
という訳でまずテストを直すPRした。これがマージさ
れれば Issue #109のやつも頑張るかも知れない。これ
がマージされないようなら、 innotop は死んだんであ
ろう（というか、死んだと思ってForkしてゴニョったや
つをrpmbuildしたらテストが通らないのに気が付い
た。。）
⽇々の覚書: innotopが最近息してないなーと思ったんだ
47/73

MySQLエコシステムの中⾝
中⾝を⾒たことのある⼈いますか︖
innotop (Perl)-
PMP for Cactiの ss̲get̲mysql̲stats.php (PHP)-
MHA for MySQL (Perl)-
どれも同じなのは、「⼈間がやるべき⾯倒くさい処理を、泥
臭く丁寧（︖）に実装してある」
48/73

innotopの⼀件で感じたこと
かっこよくなくてもいい
誰もやりたくない泥臭いことを、丁寧に
⾃分で使いたい範囲のFixなら何とかなる
⾃分が使うために作ったものが誰かの役に⽴つこともある-
49/73

mikasafabric for MySQL #とは
⾼可⽤性（High Availability）
障害探知と昇格-
データベースリクエストのアクセス先の選択-
シャーディング – スケールアウト
今のところMySQL Fabricの機能に⼿を⼊れてない-
MySQL Fabricもともとのシャーディング機能が何故かグループレプ
リケーションを要求するようになっていたので、ここは完全にサポー
ト外
-
MySQL Fabric – コネクタとの連携
プロキシ不要の構成-
MySQL Routerとの組み合わせに特化-
他のファブリック対応コネクターとも動くはずだけど未検証-
51/73

mikasafabric for MySQL
MySQL 5.7の新機能も積極的に使う
offline_mode を使ってコネクションプールとの相性を改善
0.4.0現在、ファームはMySQL 5.7.5以上必須
-
Multi-Source Replication環境下でもファームに組み込めるように改
善
-
既存のバグのFIX
prune_log, prune_error_log イベントのバグのせいでいつまでも消え
ないログテーブル
-
レプリケーションスレッドのエラーでスレーブを SPARE ステートに切
り離し
-
“ちょっと便利な” 機能
event_schedular がオフだとワーニングメッセージ-
レプリケーションユーザーの⾃動作成-
ログテーブルへの出⼒をコンフィグで設定- 52/73

MySQL Fabric(mikasafabric) + MySQL Routerの動
作
Master Slave
mysqlfabric
Monitor/Demote
Monitor/Promote
AP
AP
mysqlrouter
127.0.0.1:3306
AP
AP
mysqlrouter
127.0.0.1:3306
Lookup Group QueryRouting(NAT)
Routing(NAT)
53/73

名前解決ベースのHAに近い
MySQL Router(またはFabric-awareコネクター)がリゾルバ
ー
MySQL RouterはTTLが切れるたびにMySQL Fabricに経路
情報を問い合わせ
TTL期間内はMySQL Router内のルーティングキャッシュを使って経
路解決
-
TTL期間後でもMySQL Fabricへの経路情報の問い合わせに失敗した
らルーティングキャッシュを使い続ける
-
54/73

MySQL Router
MySQL Routerは全てのパケットを⼀度NATする
もしアプリケーションから⾒てlocalhost以外に置くなら、MySQLア
カウントの接続元はMySQL RouterのIPアドレスにしないといけない
-
遅延は数⼗us単位-
⼀度NATしている関係上、エラーパケットを捕捉して特定のエラーコ
ードなら切断するとかいうパッチもしてみた（動いた）
-
パスワードをiniファイルに書くと起動できない、書かないとプロンプ
トを出そうとするのがダメなところ（パッチでしのいでる）
-
mikasafabricでマスター昇格コマンドを叩くと2〜3秒で切
り替わる
TTLは1（mikasafabric側の設定）-
フェイルオーバーの場合、mikasafabricがファームのダウンを検知す
るまでに6秒くらいなので合わせて10秒ちょい（のはず）
-
55/73

MySQL Fabric
レプリケーションのマスター/スレーブの組を “グループ” と
呼んで管理
サーバー(mysqld)は server_uuid ごとに識別される
4つのステータス。PRIMARY, SECONDARY, SPARE, FAULTY-
56/73

サーバーごとのステータス
PRIMARY SECONDARY SPARE FAULTY
read-write Yes No No No
read-only No Yes No No
read-only &
allow̲primar
y̲reads
Yes Yes No No
フェイルオーバ
ー候補
- Yes No No
フェイルオーバ
ー時のマスター
追従
(Yes) Yes Yes No
死活監視 Yes Yes Yes No
MySQL Routerから⾒た時で、他のコネクターは違うかも知
れない
57/73

mysqlrouter.ini
[fabric_cache:hogehoge]
address = 172.17.3.202
user = mysqlrouter
#password = router_password
[routing:master]
bind_address= 0.0.0.0:13306
mode = read-write
destinations= fabric+cache://hogehoge/group/myfabric
[routing:slave_only]
mode = read-only
destinations= fabric+cache://hogehoge/group/myfabric
[routing:all_wrr]
mode = read-only
destinations= fabric+cache://hogehoge/group/myfabric&allow_primar
y_reads=yes
58/73

mysqlrouter.iniの設定
fabric̲cacheセクション
fabric_cache:xx のxxは識別名-
parameter value
address MySQL FabricのIPアドレス
user MySQL Fabricの(not バッキングストア)
ユーザー
password MySQL Fabricの(not バッキングストア)
パスワード
(ただしMySQL Router 2.0.3現在、この項目
を設定するとエラーで起動しない
59/73

mysqlrouter.iniの設定
routingセクション
routing:xx のxxは識別名-
parameter value
bind̲addres バインドするIPアドレスとポート
mode read-writeまたはread-only
destinations コンマ区切りのIPアドレス（単純なラウンド
ロビン）または
fabric+cache://Fabric識別名/group/
Fabricグループ名
allow_primary_reads={yes | no}
60/73

MySQL Router
mysqlrouter のプロセスと「マスターへのルーティング」
「スレーブへのルーティング」が別のポートでLISTENされ
る
「どっちにルーティングするためにどっちのポートを叩くか」は
MySQL Routerは判断してくれない
⼀応MySQL Routerのルーティングはプラグイン⽅式なので、将来に期待
-
mysqlrouter は全てのパケットをシングルスレッドでNATす
るので、
レイテンシーは10us未満なのでそんなに⼼配はしなくて良さげa.
300並列(Not 同時接続)とかは mysqlrouter がサチるb.
やろうと思えばクエリーの中⾝も覗けるc.
61/73

ステータス変更
PRIMARY SECONDARY SPARE FAULTY
PRIMARY - group
promote(*)
No threat
report̲failure
SECONDARY group
promote
- server
set̲status
threat
report̲failure
SPARE No server
set̲status
- threat
report̲failure
FAULTY No No server
set̲status
-
* 他のサーバーをマスターに昇格させるということ
62/73

mikasafabric for MySQLの死活監視
変更後ステータス mikasafabric特有
MySQL接続失敗(サーバーダ
ウン含む)
FAULTY No
SHOW SLAVE STATUSで
スレッドが⽌まってる
SPARE Yes
オフラインモードON FAULTY Yes
63/73

mikasafabric for MySQLのフェイルオーバー
マスターに対して SET GLOBAL read_only = 1
マスターに対して SET GLOBAL offline_mode = 1
(mikasafabric特有)
candidateに対して SELECT
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(..), STOP SLAVE,
RESET SLAVE ALL, SET GLOBAL read_only = 0
candidate以外のスレーブと旧マスターに対して STOP
SLAVE, CHANGE MASTER TO
旧マスターに対して SET GLOBAL offline_mode = 0
(mikasafabric特有)
64/73

オフラインモード (from MySQL 5.7.5)
MySQL :: MySQL 5.7 Reference Manual :: 6.1.4 Server
System Variables
SET GLOBAL offline_mode= 1 で有効化
オフラインモードだと、Super̲privを持っていないユーザ
ーは接続できない
Super̲privを持っていないユーザーのセッションは、現在
のクエリーが終了次第コネクションを切断される
これで、コネクションプールのスレッドたちを⼀度強制的に切り離せ
る
-
⽇々の覚書: MySQL 5.7.5のオフラインモードはgraceful
shutdownの夢を⾒るか
65/73

DEMO
しかしじかんがたりな
い︕︕
66/73

InnoDB Clusterとの接点
http://www.slideshare.net/mattalord/mysql-high-
availability-innodb-clusters
67/73

InnoDB Cluster
グループレプリケーション(5.7.15-preview) をメインに置
いたHA構成
MySQL Router(2.1.0-preview) のMetadata Cacheプラグ
インとMySQL Fabric Cacheプラグインは非常に似たつくり
HA情報の問い合わせ先が違うだけ。-
どちらもMySQL Routerから⾒ると CALL でストアドファンクション
を呼び出す
-
68/73

MySQL Fabirc vs InnoDB Cluster
MySQL Fabric InnoDB Cluster
同期⽅式非同期レプリケーション同期グループコミュニケーシ
ョン
死活監視 mysqlfabricデーモン多分メンバー同⼠のグループ
コミュニケーション
状態の操作 mysqlfabricコマンド MySQL Shell
69/73

非同期ベース, 同期
ベースでユースケ
ースは分かれてい
く（かも）
70/73

mikasafabric for MySQLということ
MySQL Fabricを使いたいおじさんが、⾃分で使うために
パッチしている
MySQL Fabric 1.6.0がlabsにあった時期があって、このまま1.5.6ベ
ースで⾏くかどうかは微妙だけれど、それでも「ある程度期待通りに
動くMySQL Fabric」として使える程度にはメンテナンスするはず
-
本家のメンテナンスが終わった（︖）以上、mikasafabric for
MySQLはポストMHAとして⼿間をかける理由になった
-
⾃分で⾔うのもアレだけど、MySQL 5.7 + MySQL Fabric
+ MySQL Routerの組み合わせで運⽤だったら⽇本で⼀番詳
しい気がする
だから、その組み合わせだけに特化して（それでも⼤概のユースケー
スには上⼿く合う）「DBAが本当に必要だったもの」を追加する
-
71/73

mikasafabric
for MySQL をよ
ろしくお願いしま
す :)
72/73

Questions
and/or
Suggestions?
73/73

MHAの次を目指す mikasafabric for MySQL

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to MHAの次を目指す mikasafabric for MySQL (7)

More from yoku0825 (9)

MHAの次を目指す mikasafabric for MySQL