MHAの次を目指す mikasafabric for MySQL

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

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

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

4. Do you know MySQL Fabric ︖ 3/73

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

6. 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

7. 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

8. つまり 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

9. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

29. 存在しない 28/73

30. 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

31. 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

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

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

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

35. あっ（察し 34/73

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

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

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

39. これなんかひどい 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

40. これもひどい 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

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

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

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

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

45. つらい [はい/Yes] 44/73

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

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

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

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

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

51. 脱線しました 50/73

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

53. 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

54. 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

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

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

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

58. サーバーごとのステータス 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

59. 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] bind_address= 0.0.0.0:23306 mode = read-only destinations= fabric+cache://hogehoge/group/myfabric [routing:all_wrr] bind_address= 0.0.0.0:33306 mode = read-only destinations= fabric+cache://hogehoge/group/myfabric&allow_primar y_reads=yes 58/73

60. 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

61. 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

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

63. ステータス変更 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

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

65. 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

66. オフラインモード (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

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

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

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

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

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

72. 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

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

74. Questions and/or Suggestions? 73/73