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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

More from yoku0825

More from yoku0825 (9)

Recently uploaded

Recently uploaded (11)

MHAの次を目指す mikasafabric for MySQL