Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zabbix+group replication

zabbix+ProxySQL+HAPROXY+MySQL group replication

  • Login to see the comments

Zabbix+group replication

  1. 1. Zabbix+Group replication ブリンガー
  2. 2. 自己紹介 HN:ブリンガー (Qiitaとかはbringer1092) 職業:提督 年齢:37 経歴:秋葉原店員、NW・インフラ・(クラウド)エンジニア、転職活動中 興味あること:Zabbix、MySQL、Docker、Hinemos 嫌いなこと:ノーインフラ(エンジニア)時代、無茶なスケジュール
  3. 3. InnoDB Cluster発表時 これでZabbixが閲覧ユーザが爆増増えても耐えられる仕組みが作れそう! MySQL-MHAは会社に1から導入するにはちょっと大変だったし これとMySQL Document Storeを併用したら
  4. 4. 当初の構想
  5. 5. どういうケースを想定しているか ・アプリケーションが1台のMySQLサーバしか考えられていない物 ・今まで(Virtual)IPで書き込み、読み込み処理を分けていたサービス 認証、課金はProxySQLのパスワード制約があるため ProxySQLを飛ばしHAproxyにSELECTはスレーブをまず参照し、データがなければマ スターに参照するなど別実装を推奨
  6. 6. Maxscaleではなくなった理由 https://mariadb.com/kb/en/mariadb-enterprise/named-server-filter/ This is the server where matching queries will be router. The server should be in use by the service which uses this filter. これは、一致するクエリがルーティングするサーバです。サーバーは、このフィルターを 使用するサービスで使用されている必要があります。 英語はきちんと読みましょう
  7. 7. 書き込み・読み込みサービス Server1指定 :3306 MySQLマスター server1 MySQLスレーブ server3 図解 MySQLスレーブ server2 ^select.* フィルタ適応 server2,3指定NG NG
  8. 8. 色々複雑なことしなくてもいいのではないか? ・PHPなんだからphp-mysqlndならmysqlnd_ms使って書き込みと読み込み分けられる よね? というツッコミはあると思います。 ですがもっと柔軟でないとアプリ次第で困ることがあります ・マルチマスターで動かせは? とあると思いますが同期が遅れているサーバをどうやって検出するか、競合が起きない アプリであるのかマルチマスターでも課題はあります
  9. 9. 変わりにProxySQLを採用 利点: 複数フィルタ適応可能など柔軟なSQLのフィルタルールが作成可能 どのフィルタにマッチしたか統計が取れる 欠点: 簡単に説明するとコンフィグがコンフィグファイル、SQLite、メモリと3段階あり面倒 MysqlコマンドでSQLiteに接続するため勘違いしやすい Note:ProxySQL currently doesn’t encrypt passwords.(実装する気はありそう)
  10. 10. MysqlRouterではなくなった理由 ONLINE判定がない モニタリングがない サンプルでHAproxyが使われている http://lefred.be/content/mysql-group-replication-as-ha-solution/
  11. 11. HAproxyなら 利点: 汎用ロードバランサではあるがHTTPであればL7として動作可能 OKなら200が返ってくるなら万が一シングルマスターなのに高負荷でマスターが2台に 万が一なってもプロクシ側で検知が出来、haproxyを落とせる モニタがある。GUIでもCUIでも簡単に見られるのは便利 欠点: 公式推奨のnbproc=1だと性能の頭打ちがある
  12. 12. 最終的に every 5sec Script(plan) :6446 200 ok 2server HAproxy forced down 200 ok 0server alert And select session table
  13. 13. 全テーブルにPRIMARY KEYかUNIQ KEYが必要 Zabbixだと4つのテーブル(history、history_str、history_uint、dbversion) でPKもUKも存在しなかった。 ALTER TABLEを実施する必要があります。 ただし、新規にPKを追加する場合はオンラインDDLが可能なようです(※要検証)
  14. 14. 本番データを食べさせて動作させてみて Zabbixではこういう振り分けになりました。番号順に評価されます 1.^SELECT以外を書き込みポートに振り分け 2. sessionという文字があれば書き込みポートに振り分け 3. zabbixユーザのアクセスは読み込みポートに振り分け 4.^SELECTを書き込みポートに振り分け
  15. 15. Mysql_query_rules{ ( { rule_id=1 active=1 username=”zabbix” match_pattern=”^SELECT” destination_hostgroup=0 negate_match_pattern=1 apply=1 } ) } 1番から評価 設定を有効にするか 接続ユーザ 一致する条件 どのホスト(グループ単位)に送信するか 条件にNOTに一致しない場合 このフィルタで終わらせるか
  16. 16. ProxySQLのSQLルールが柔軟で助かる 接続ユーザ、schema、接続元IP、ポートでも振り分け可能 いくつものルールを適応できるapply=0(次も評価)、flagOUT=xx(次の処理を指定)、 flagIN=xx(前の処理を指定) 大文字小文字は気にしなくて良さげ クエリ書き換えもどうしても必要なら5.7側よりプロクシでやらせたほうがいいかな どの正規表現規格に準拠しているかわからないのが難点
  17. 17. proxysqlのトラブルシュート クエリがルールに適応されているか select active,hits, mysql_query_rules.rule_id, match_digest, match_pattern, replace_pattern, cache_ttl, apply,flagIn,flagOUT FROM mysql_query_rules NATURAL JOIN stats.stats_mysql_query_rules ORDER BY mysql_query_rules.rule_id; サーバが接続されているか SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start DESC LIMIT 6; サーバが生きているか SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start DESC LIMIT 6;
  18. 18. 悩み 何かあったらGTIDとグループレプリケーションの両方の知識が必要になる mysqldumpで--single-transactionが使えるようにならないとDBだけで4台必要 group_replication2台目以降の接続にdry-runが欲しい(こけた時にマスターのhaproxy 判定まで影響したことが) group_replicationの前提条件が多すぎて(13項目)移管するならコンフィグチェックツー ルが欲しくなる

×