mhaの次を目指す mikasafabric for mysql

MHAの次を目指すmikasafabric for MySQL

今年のアドベントカレンダー2016/11/05

yoku0825OSC 2016 Tokyo/Fall

＼こんにちは／

yoku0825＠とある企業のDBAオラクれない-ポスグれない-マイエスキューエる-

家に帰ると妻の夫-せがれの⽗-ムスメの⽗-

⽣息域Twitter: @yoku0825-Blog: ⽇々の覚書-MyNA ML: ⽇本MySQLユーザ会-MySQL Casualʼs Slack: MySQL Casual-

1/73

https://twitter.com/yoku0825

https://yoku0825.blogspot.jp

http://mysql.gr.jp/

http://mysql-casual.org/

mikasafabric for MySQL #とは

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

2/73

https://github.com/gmo-media/mikasafabric

Do you know MySQL

Fabric ︖3/73

MySQL Fabric #とは

⾼可⽤性（High Availability）障害探知と昇格-データベースリクエストのアクセス先の選択-

シャーディング – スケールアウトMySQL Fabric – コネクタとの連携プロキシ不要の構成-

MySQL :: MySQL Fabric

4/73

https://www-jp.mysql.com/products/enterprise/fabric.html

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

https://code.google.com/p/mysql-master-ha/

MHA for MySQLとの⽐較

MHA for MySQL MySQL Fabric

マネージャプロセス masterha̲manager mysqlfabric

マネージャの状態確認ログのみ mysqlfabricコマンド (デーモンと同じコマンド)

エージェントライブラリなし

切り替わり時のリカバリー⼀番進んでいるスレーブのリレーログから(via SSH)

なし

切り替わりの処理 master̲ip̲failover̲script ファブリック対応コネクター依存

処理フック master̲ip̲failover̲script, secondary̲check̲script, shutdown̲script, report̲script

SERVER̲LOST, SERVER̲PROMOTED, SERVER̲DEMOTEDが予約されているが、Pythonで直書き

構成の検出⾃動⼿動で登録

サーバーの追加, 削除コンフィグ編集, 再起動 mysqlfabricコマンド

8/73







なし






9/73

マネージャプロセス

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

-

マネージャプロセスのダウンは切り替わりができないだけで、サービスそのものに影響は出ない

10/73







なし






11/73

マネージャの状態確認

MHA for MySQLはプロセスの内部にマスター/スレーブの情報を持ち、APIは特に⽤意されていない

masterha_master_monitor はマネージャから情報を惹くのではなく、⾃分が起動してMySQLの状態をチェックする

-

MySQL Fabricは、管理対象とは別のMySQL（バッキングストア）に構成情報を保存する

mysqlfabricデーモンがMySQLプロトコルとXMLRPCプロトコルでAPIを持っている

-

バッキングストアが落ちるとmysqlfabricデーモンが落ち…てくれずに刺さる

-

12/73







なし






13/73

エージェント

MHA for MySQLのエージェントは常駐型ではないいくつかのコマンドを提供する mha4mysql-node をインストールする-mha4mysql-node の提供するコマンドをSSH経由でマネージャーが叩く-

MySQL Fabricはフェイルオーバーなどに必要な全ての動作をSQLだけで実装しているためエージェントが要らない拡張する場合はSQLでできることをやらせないといけない-

14/73







なし






15/73

切り替わり時のリカバリー

MHA for MySQLは⼀番進んでいるスレーブのリレーログをチェックして差分を読み込み、実⾏させるポジションを判定してseek(), read() で読む-

MySQL Fabricは⼀番進んでいるスレーブを次のマスターに選ぶものの、リカバリー処理⾃体は存在しない受け取ったリレーログをすべて適⽤するまで待つだけ-Semisyncレプリケーション必須-

16/73







なし

切り替わりの処理 master̲ip̲failover̲script

ファブリック対応コネクター依存





17/73

切り替わりの処理（主にIPのつけかえ）

MHA for MySQLは master_ip_failover_script に切り替わりの処理を書く

VIPの付け替えだったり、DNSの更新だったり-read_only の設定変更だったり、新しいレプリケーションユーザーを作ったりの処理もここに書くことができる

-

MySQL Fabricは切り替わりはコネクターが吸収するバッキングストアに持っているマスター/スレーブの状態を更新し、-ファブリック対応コネクターが次にHAグループ情報を参照してきた時にコネクター側に反映される

-

MySQL RouterもFabric対応コネクターと⾒做せる-デフォルトのTTLは1秒-

18/73







なし






19/73

処理フック

MHA for MySQLはいい感じのところにフックがあり、それぞれ⾃分の好きなスクリプトで書けば良いこれにより、応答がなくなった旧マスターをOSごとシャットダウンする、という荒業も可能に

-

MySQL Fabricもイベントトリガーは予約されているものの、設定ファイルではどうにもならない更に、SSHも利⽤できるMHAに対してMySQL FabricはSSHのセットアップを要求しないので、出来ることは限られている

-

とはいえ単にスクリプトを叩くようにイベントを書けばいいはず-

20/73







なし






21/73

構成の検出

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

-

22/73







なし






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

存在しない

28/73

MySQL Fabricのパッケージング

MySQL Fabric 1.4MySQL Utilities 1.4に同梱

MySQL Fabric 1.5MySQL Utilities 1.5に同梱

MySQL Fabric 1.6MySQL 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

あっ（察し

34/73

先が無いことを⾒抜くのは難しい (c)matsunobu

「先が無い」とは誰も⾔ってくれない

興味の無いものに対してわざわざ情報発信してベンダー

に喧嘩を売る動機は無い

..

先が無い技術を選んで⼀番痛い目を⾒るのはその採⽤企

業とエンジニア

http://www.slideshare.net/matsunobu/ss-28303485/31

35/73

諦めますか︖ [No/否]

36/73

というよりは最初から諦めていた

MySQL FabricつらいMySQL Fabricつらい Advent Calendar 2014MySQL Fabric＆Routerつらくない Advent Calendar 2015MySQL Fabricでぼっこぼこにされたはなし

37/73

http://www.slideshare.net/yoku0825/mysql-fabric-42641503

http://qiita.com/advent-calendar/2014/mysql_fabric

http://qiita.com/advent-calendar/2015/mysql_fabric

http://www.slideshare.net/yoku0825/mysql-fabric-63658850

これなんかひどい

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

http://bugs.mysql.com/bug.php?id=81557

これもひどい

status compares (not equal) with string ʻFAULTYʼ

but status has integer datatype.

mysql> SELECT server_uuid, group_id, server_address, mode, status, weight FROM servers WHERE group_id LIKE '%%' AND group_id IS NOT NULL AND status != 'FAULTY' ORDER BY group_id, server_address, 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

http://bugs.mysql.com/bug.php?id=81559

作ったやつ出てこい

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

40/73

だいぶ考えたこと

MHA for MySQLは流⾏っているとはいえ⾃分で使うのに⾜りない機能があって

relay_log_info_repository= TABLE の場合起動できないMHA for MySQL⾃体を監視する⼿段が微妙あんまりメンテナンスされてる気配がない

-

MySQL Fabricだって考え⽅⾃体は間違っていなかったはずだ死活監視とマスター切り替えを備えたフレームワークという⽅向性-死活監視がちょっとイケてなくて、エラーハンドルがイケてなくて、補助機能が貧弱すぎて、ログ機構が極悪なだけ

-

シャーディングのことは忘れることにする-

41/73

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

42/73

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

⼈︖43/73

つらい[はい/Yes]

44/73

オレオレパッチの運⽤

メインラインのバージョン固定してパッチしてビルドしてはいおしまい、なら楽

ex. mysql コマンドラインクライアント, mysqldump なんかはバージョンアップしたところでそんなに機能が変わらないから、バージョンを固定してビルドするのは⼗分現実的

-

メインラインが⽣きていて新機能が追加され続ける場合、追従しないといけないメインラインが別の実装で同じ機能を作ったり-非互換のAPI変更があったり-テスト書くのつらい-

45/73

半年くらい悩んだ結果

あまりにもつらかったので、おとなしくフォークして⾃

前でパッチを当てることにしました。フォークするつい

でに名前を変えたのが mikasafabric for MySQLになり

ます。

期待通りに使えるMySQL Fabricを目指した結果なの

で、まあまあ期待通りに動きます

mikasafabric for MySQLをオープンソースライセンスで公開しました | GMOメディアエンジニアブログ

46/73

http://tech.gmo-media.jp/post/149111752114/starting-mikasafabric-for-mysql

悩んだ経緯

というか、 “Support MySQL 5.7” と銘打たれたコミッ

トがひどすぎて、テストすら通らない（何故マージされ

たし）

という訳でまずテストを直すPRした。これがマージさ

れれば Issue #109のやつも頑張るかも知れない。これ

がマージされないようなら、 innotop は死んだんであ

ろう（というか、死んだと思ってForkしてゴニョったや

つをrpmbuildしたらテストが通らないのに気が付い

た。。）

⽇々の覚書: innotopが最近息してないなーと思ったんだ

47/73

https://yoku0825.blogspot.jp/2016/05/innotop.html

MySQLエコシステムの中⾝

中⾝を⾒たことのある⼈いますか︖innotop (Perl)-PMP for Cactiの ss̲get̲mysql̲stats.php (PHP)-MHA for MySQL (Perl)-

どれも同じなのは、「⼈間がやるべき⾯倒くさい処理を、泥臭く丁寧（︖）に実装してある」

48/73

innotopの⼀件で感じたこと

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

49/73

脱線しました

50/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環境下でもファームに組み込めるように改善

-

既存のバグのFIXprune_log, prune_error_log イベントのバグのせいでいつまでも消えないログテーブル

-

レプリケーションスレッドのエラーでスレーブを SPARE ステートに切り離し

-

“ちょっと便利な” 機能event_schedular がオフだとワーニングメッセージ-レプリケーションユーザーの⾃動作成-ログテーブルへの出⼒をコンフィグで設定- 52/73

MySQL Fabric(mikasafabric) + MySQL Routerの動作

Master Slave

mysqlfabric

Monitor/Demote

Monitor/Promote

AP

AP

mysqlrouter127.0.0.1:3306

AP

AP

mysqlrouter127.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̲primary̲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.202user = mysqlrouter#password = router_password

[routing:master]bind_address= 0.0.0.0:13306mode = read-writedestinations= fabric+cache://hogehoge/group/myfabric

[routing:slave_only]bind_address= 0.0.0.0:23306mode = read-onlydestinations= fabric+cache://hogehoge/group/myfabric

[routing:all_wrr]bind_address= 0.0.0.0:33306mode = read-onlydestinations= fabric+cache://hogehoge/group/myfabric&allow_primary_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 = 0candidate以外のスレーブと旧マスターに対して 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 VariablesSET GLOBAL offline_mode= 1 で有効化オフラインモードだと、Super̲privを持っていないユーザーは接続できないSuper̲privを持っていないユーザーのセッションは、現在のクエリーが終了次第コネクションを切断されるこれで、コネクションプールのスレッドたちを⼀度強制的に切り離せる

-

⽇々の覚書: MySQL 5.7.5のオフラインモードはgraceful shutdownの夢を⾒るか

65/73

http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_offline_mode

https://yoku0825.blogspot.jp/2014/09/mysql-575graceful-shutdown.html

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

https://github.com/gmo-media/mikasafabric

Questions and/or

Suggestions?73/73

mhaの次を目指す mikasafabric for mysql

Technology