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.
(続)MySQL Group Replication
2017/02/01 MySQL Casual Talk vol.10
@mita2
2
前回(2016/05のMyNA会)
のおさらい
前回:Group Replication Labs まとめ
• 導入はすごい楽
• 手軽の高可用性構成が組める
• 8.0 入りに期待
3
前回:Group Replication Labs まとめ
• 導入はすごい楽
• 手軽の高可用性構成が組める
• 8.0 入りに期待
4
5
しかし・・・
5.7 でリリースされた
6
7
5.7 GA とは何だったのか…~
5.7 GAとは何だったのか履歴
8
5.7 GAとは何だったのか履歴
• 5.7.11 InnoDB Tablespace encryption
• 5.7.12 X Protocol, MySQL Document Store
• 5.7.17 new! Group Repli...
5.7 GAとは何だったのか履歴
• 5.7.11 InnoDB Tablespace encryption
• 5.7.12 X Protocol, MySQL Document Store
• 5.7.17 new! Group Repli...
自己紹介
• 三谷 智史(@mita2)
• MySQL DBA
• 最近の興味
• OpenStack Trove
• Percona XtraDB Cluster
• Group Replication
11
本日の内容
12
1. 何ができるのか
2. 仕組み
3. ロックの挙動
4. 障害時の挙動
5. flow control
6. 導入方法
7. まとめ
本日の内容
13
1. 何ができるのか
2. 仕組み
3. ロックの挙動
4. 障害時の挙動
5. flow control
6. 導入方法
7. まとめ
高可用性ソリューション
• マルチライター構成が組める
• 高可用性ソリューション
• 性能向上を主目的としたものではない
14
MasterMaster MasterMaster MasterMaster MasterMaster Maste...
自動リカバリー
15
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
• 障害を自動検知し、データ同期対象から切り離す
• 復旧時には差分を自動的にリカバリ
構成パターン
16
MasterMaster
Read only
Master
Read only
Master
Read only
Master
Read only
Master
Single Primary
• 従来のマスター/スレーブに相...
本日の内容
17
1. 何ができるのか
2. 仕組み
3. ロックの挙動
4. 障害時の挙動
5. flow control
6. 導入方法
7. まとめ
通常レプリにGroup Replication レイヤーが追加
18
引用元:https://www.percona.com/live/data-performance-conference-2016/content/high-availabi...
レプリケーション
19
• いつものレプリケーションは普段は動かない
mysql> SHOW SLAVE STATUS FOR CHANNEL 'group_replication_recovery' ¥G
******************...
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
UPDATE t
SET col = ‘B’
WHERE pk = 2
UPDATE t
SET col = ‘B...
スレーブをぶらさげてもOK
21
Async
Slave
Async
Slave
Async
Slave
Async
Slave
Group Replication
WriteWrite
ReadRead
スレーブのマスターの切り替えも簡単
22
Async
Slave
Async
Slave
Async
Slave
Async
Slave
Group Replication
WriteWrite
ReadRead
23
MGRが今後スタンダードに
な(ってほしいな|るはず)
理由
• たくさんのDBを管理していると・・・
24
理由
• たくさんのDBを管理していると・・・
• なるべく同じ構成で管理したい
• マスター・スレーブですらツライ
• DBサーバ以外のサーバ増やしたくない
• MHAのmanager、MySQL fabric など
• なるべくビルドインさ...
理由
• サーバの「生きてる」「死んでる」だけ意識すれば良い
• ロードバランサの運用はツラくない(はず)
• Webサーバでたくさん使ってるよね?
26
MasterMaster MasterMaster MasterMaster
LBLB
本日の内容
27
1. 何ができるのか
2. 仕組み
3. ロックの挙動
4. 障害時の挙動
5. flow control
6. 導入方法
7. まとめ
非 Group Replication 構成の場合
時間 行の値 トランザクション1 トランザクション2
T1 - mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE...
非 Group Replication 構成の場合
時間 行の値 トランザクション1 トランザクション2
T1 - mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE...
Group Replication 構成の場合
30
時間 行の値 トランザクション1 on ノード1 トランザクション2 on ノード2
T1 - mysql> BEGIN;
Query OK, 0 rows affected (0.00 s...
Group Replication 構成の場合
31
時間 行の値 トランザクション1 on ノード1 トランザクション2 on ノード2
T1 - mysql> BEGIN;
Query OK, 0 rows affected (0.00 s...
本日の内容
32
1.何ができるのか
2.仕組み
3.ロックの挙動
4.障害時の挙動
5.導入方法
6.まとめ
ノードダウン後の挙動
• 自動的に同期対象から外れる
• キャッチアップするまでは「RECOVERING」ステータス
33
mysql> SELECT * FROM performance_schema.replication_group_me...
• いつものレプリケーションはリカバリー時にうごく
34
[Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'.
Previous state m...
すでにbinlogがなくなってるパターン
ちなみに、
• Galera では State Snapshot Transferで自動全コピー
• 内部的にはxtrabackup or mysqldump or rsync
35
すでにbinlogがなくなってるパターン
• MGR では binlog が既にpurgeされているとあきらめる
• ノード追加時は既存ノードからのデータコピーが必要
36
[ERROR] Slave I/O for channel 'grou...
ノード リカバリ手順
37
1. 生きてるノードからmysqldumpする
2. 壊れたノードに投入
3. START GROUP REPLICATION
mysqldump に注意
• MGR は Savepoint をサポートしてない
• --single-transacation が使えない ※
38
-bash-4.1$ mysqldump --all-databases --single...
mysqldump に注意
• --lock-all-tables は 書き込みがブロックされる
• mysqldump するノードは外す必要がある
• スレーブがあればスレーブからでも可
39
MasterMaster MasterMaste...
40
SplitBrain 時の挙動
Split Brain とは
• クラスターが複数のセットに分断されてしまうこと
• どっちを生かすか?
• 「過半数を生かす」戦略が一般的
• MGRでは3台以上での構成必須
41
11 22 33
ClientClient
他の2台が
見え...
少数派では更新がブロックされる
mysql> SELECT * FROM tbl;
+------+
| c1 |
+------+
| 0 |
+------+
4 rows in set (0.00 sec)
mysql> INSERT I...
多数派のほうは継続稼動
mysql> SELECT * FROM tbl;
+------+
| c1 |
+------+
| 2 |
+------+
4 rows in set (0.00 sec)
mysql> INSERT INTO ...
• サーバの「生きてる」「死んでる」だけ意識すれば良い
44
LBLB• Split Brain を意識した判定が必要
11 22 33
Split Brain を意識した判定
45
mysql> SELECT MEMBER_HOST,MEMBER_STATE FROM
performance_schema.replication_group_members;
+--------...
MGR用 死活監視スクリプト
• 中の人(lefred) がスクリプトをすでに作ってくれている
• HAProxy と組み合わせて使える
46
https://github.com/lefred/mysql_gr_routing_check
47
flow control
flow control
• ノード間の遅延を最小限にする仕組み
• 遅れたノードがほかのノードに「待った」をかける
• 閾値の設定
48
mysql> SHOW GLOBAL VARIABLES LIKE '%flow%threshold%'...
Certification と Apply
49
11 22 33
UPDATE
CertificationCertification
http://mysqlhighavailability.com/mysql-group-replicati...
テスト
• 3台中1台に向けてベンチマークを流す
• ベンチを流しているノードと違うノードでDISK IOを絞る
50
11 22 33
sysbench
テスト結果
51
0
50
100
150
200
250
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 6...
テスト結果
52
0
50
100
150
200
250
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 6...
flow control の発動確認
• flow control が発動したことを確かめる方法が見あたらず
• member_stats を定期的にモニターしておく?
53
mysql> select * from performance_s...
本日の内容
54
1.何ができるのか
2.仕組み
3.ロックの挙動
4.障害時の挙動
5.導入方法
6.まとめ
STEP1: インストールとユーザ作成
55
• レプリケーションユーザを作成しておく
• この時点でbinlogはまだ有効化してはいけない
mysql> CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rp...
STEP2-1:レプリケーション設定
• GTID
• log-slave-updates
• {master,relay}-log-info-repository=TABLE
• binlog-format=row
56
server_id=...
STEP2-2:Group Replication 設定
57
# Group Replication の設定
transaction_write_set_extraction=XXHASH64
# SELECT UUID() で生成した任意の...
STEP3:Group Replication 開始
58
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
FOR CHANNEL 'grou...
STEP3:Group Replication 開始
59
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass'
FOR CHANNEL 'grou...
STEP4:Group Replication 開始
60
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)...
STEP5:ステータス確認
61
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+---------...
MGR 制限事項
• InnoDB のみサポート
• PK or UNIQUE キーが必須
• GTID + ROW ベースレプリケーション
• トランザクション分離レベルはREAD-COMMITED
• 複数の同じテーブルに対するDDLとDM...
本日の内容
63
1.何ができるのか
2.仕組み
3.ロックの挙動
4.障害時の挙動
5.導入方法
6.まとめ
Galera Cluster、従来構成 との比較表
Group Replication Galera Cluster 通常のマスター昇格
1 マルチライター 対応 対応 非対応
2 データ同期の仕組み GTID Replication base...
参考資料
• Oracle社 2017年1月25日 MySQL Tech Tour講演資料
MySQLの新しい高可用性構成
MySQLグループ・レプリケーション
• https://www-jp.mysql.com/why-
mysql/pre...
まだ試してないこと
• DDLの流し方、ベストプラクティス
• パフォーマンス
• ノードを増やしたときの性能劣化度合い
• Galeraとの比較。Galera より速いらしい
66
http://mysqlhighavailability.c...
67
~ ご案内 ~
ご案内
68
• MySQL Casual Slack
• https://t.co/QobukOxvUw
• 日本MySQL ユーザ会 ML
• http://mysql.gr.jp/ml.html
まとめ
• Group Replication 5.7 で GAになったよヾ(@^▽^@)ノ
• マルチライター盛り上げていきましょう
69
70
Enjoy MySQL
Upcoming SlideShare
Loading in …5
×

MySQL Group Replication - MySQL Casual Talk vol.10

3,613 views

Published on

MySQL Group Replication - MySQL Casual Talk vol.10

Published in: Engineering
  • Be the first to comment

MySQL Group Replication - MySQL Casual Talk vol.10

  1. 1. (続)MySQL Group Replication 2017/02/01 MySQL Casual Talk vol.10 @mita2
  2. 2. 2 前回(2016/05のMyNA会) のおさらい
  3. 3. 前回:Group Replication Labs まとめ • 導入はすごい楽 • 手軽の高可用性構成が組める • 8.0 入りに期待 3
  4. 4. 前回:Group Replication Labs まとめ • 導入はすごい楽 • 手軽の高可用性構成が組める • 8.0 入りに期待 4
  5. 5. 5 しかし・・・
  6. 6. 5.7 でリリースされた 6
  7. 7. 7 5.7 GA とは何だったのか…~
  8. 8. 5.7 GAとは何だったのか履歴 8
  9. 9. 5.7 GAとは何だったのか履歴 • 5.7.11 InnoDB Tablespace encryption • 5.7.12 X Protocol, MySQL Document Store • 5.7.17 new! Group Replication 9
  10. 10. 5.7 GAとは何だったのか履歴 • 5.7.11 InnoDB Tablespace encryption • 5.7.12 X Protocol, MySQL Document Store • 5.7.17 new! Group Replication 10
  11. 11. 自己紹介 • 三谷 智史(@mita2) • MySQL DBA • 最近の興味 • OpenStack Trove • Percona XtraDB Cluster • Group Replication 11
  12. 12. 本日の内容 12 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ
  13. 13. 本日の内容 13 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ
  14. 14. 高可用性ソリューション • マルチライター構成が組める • 高可用性ソリューション • 性能向上を主目的としたものではない 14 MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘A’ WHERE pk = 1 UPDATE t SET col = ‘A’ WHERE pk = 1
  15. 15. 自動リカバリー 15 MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster • 障害を自動検知し、データ同期対象から切り離す • 復旧時には差分を自動的にリカバリ
  16. 16. 構成パターン 16 MasterMaster Read only Master Read only Master Read only Master Read only Master Single Primary • 従来のマスター/スレーブに相当 • 任意の1台のみWriteが可能になる MasterMaster MasterMaster MasterMaster Multi Writer 構成 • 全部に読み書き • 最大限の可用性 group_replication_single_primary_mode=FALSEgroup_replication_single_primary_mode=TRUE
  17. 17. 本日の内容 17 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ
  18. 18. 通常レプリにGroup Replication レイヤーが追加 18 引用元:https://www.percona.com/live/data-performance-conference-2016/content/high-availability-using-mysql-group-replication
  19. 19. レプリケーション 19 • いつものレプリケーションは普段は動かない mysql> SHOW SLAVE STATUS FOR CHANNEL 'group_replication_recovery' ¥G *************************** 1. row *************************** Slave_IO_State: Master_Host: <NULL> Master_User: rpl_user Master_Port: 0 Connect_Retry: 60 Master_Log_File: Read_Master_Log_Pos: 4 Relay_Log_File: gr01.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: Slave_IO_Running: No Slave_SQL_Running: No
  20. 20. MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘A’ WHERE pk = 1 UPDATE t SET col = ‘A’ WHERE pk = 1 Full GTID Support 20 • どこに書いても同じUUIDのGTIDが発行される • group_replication_group_name で指定したものがUUIDになる aaa-bbb-111:10 ⇒ pk=1 col=A aaa-bbb-111:20 ⇒ pk=2 col=B aaa-bbb-111:10 ⇒ pk=1 col=A aaa-bbb-111:20 ⇒ pk=2 col=B binlog
  21. 21. スレーブをぶらさげてもOK 21 Async Slave Async Slave Async Slave Async Slave Group Replication WriteWrite ReadRead
  22. 22. スレーブのマスターの切り替えも簡単 22 Async Slave Async Slave Async Slave Async Slave Group Replication WriteWrite ReadRead
  23. 23. 23 MGRが今後スタンダードに な(ってほしいな|るはず)
  24. 24. 理由 • たくさんのDBを管理していると・・・ 24
  25. 25. 理由 • たくさんのDBを管理していると・・・ • なるべく同じ構成で管理したい • マスター・スレーブですらツライ • DBサーバ以外のサーバ増やしたくない • MHAのmanager、MySQL fabric など • なるべくビルドインされたものを使いたい 25
  26. 26. 理由 • サーバの「生きてる」「死んでる」だけ意識すれば良い • ロードバランサの運用はツラくない(はず) • Webサーバでたくさん使ってるよね? 26 MasterMaster MasterMaster MasterMaster LBLB
  27. 27. 本日の内容 27 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ
  28. 28. 非 Group Replication 構成の場合 時間 行の値 トランザクション1 トランザクション2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; T3 - トランザクション1のロック開放待ち T4 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) トランザクション1のロック開放待ち T5 A Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T6 B mysql> COMMIT; Query OK, 0 rows affected (0.00 sec)
  29. 29. 非 Group Replication 構成の場合 時間 行の値 トランザクション1 トランザクション2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; T3 - トンラザクション1のロック開放待ち T4 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) トランザクション1のロック開放待ち T5 A Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T6 B mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) • 更新は1ノード(マスター)に対してのみ実行可 • ロックが競合した場合、後続は「待つ」 • 更新は1ノード(マスター)に対してのみ実行可 • ロックが競合した場合、後続は「待つ」
  30. 30. Group Replication 構成の場合 30 時間 行の値 トランザクション1 on ノード1 トランザクション2 on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) (ノード1の更新内容が伝わってくる) T4 A mysql> COMMIT; ERROR 1180 (HY000): Got error 149 during COMMIT
  31. 31. Group Replication 構成の場合 31 時間 行の値 トランザクション1 on ノード1 トランザクション2 on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) T4 A mysql> COMMIT; ERROR 1180 (HY000): Got error 149 during COMMIT • 異なるノードでロックが競合した場合、「先勝ち」 • 同じノードであれば、非GR構成と同じ挙動 • ロックの挙動を変えたくなければ、Single-Primary で運用 • 異なるノードでロックが競合した場合、「先勝ち」 • 同じノードであれば、非GR構成と同じ挙動 • ロックの挙動を変えたくなければ、Single-Primary で運用
  32. 32. 本日の内容 32 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 5.導入方法 6.まとめ
  33. 33. ノードダウン後の挙動 • 自動的に同期対象から外れる • キャッチアップするまでは「RECOVERING」ステータス 33 mysql> SELECT * FROM performance_schema.replication_group_members¥G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: b8be95fe-18d0-11e6-ac6f-70e2840d82f2 MEMBER_HOST: gr01 MEMBER_PORT: 3306 MEMBER_STATE: ONLINE *************************** 2. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: f95aeb40-18d2-11e6-8b47-70e2840d82cc MEMBER_HOST: gr0 MEMBER_PORT: 3306 MEMBER_STATE: RECOVERING 2 rows in set (0.00 sec)
  34. 34. • いつものレプリケーションはリカバリー時にうごく 34 [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host=‘gr02', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host=‘gr02', master_port= 3306, master_log_file='', master_log_pos=4, master_bind=''. New state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. • リカバリ開始 • リカバリ完了
  35. 35. すでにbinlogがなくなってるパターン ちなみに、 • Galera では State Snapshot Transferで自動全コピー • 内部的にはxtrabackup or mysqldump or rsync 35
  36. 36. すでにbinlogがなくなってるパターン • MGR では binlog が既にpurgeされているとあきらめる • ノード追加時は既存ノードからのデータコピーが必要 36 [ERROR] Slave I/O for channel 'group_replication_recovery': Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.', Error_code: 1236 [ERROR] Plugin group_replication reported: 'Maximum number of retries when trying to connect to a donor reached. Aborting group replication recovery.' [Note] Plugin group_replication reported: 'Terminating existing group replication donor connection and purging the corresponding logs.' [ERROR] Plugin group_replication reported: 'Fatal error during the Recovery process of Group Replication. The server will leave the group.'
  37. 37. ノード リカバリ手順 37 1. 生きてるノードからmysqldumpする 2. 壊れたノードに投入 3. START GROUP REPLICATION
  38. 38. mysqldump に注意 • MGR は Savepoint をサポートしてない • --single-transacation が使えない ※ 38 -bash-4.1$ mysqldump --all-databases --single-transaction -uroot --triggers --routines --events -p mysqldump: Couldn't execute 'SAVEPOINT sp': The MySQL server is running with the --transaction-write-set-extraction!=OFF option so it cannot execute this statement (1290) • (一貫性のあるバックアップを取るために) --lock-all-tables を使う @yyamasaki1 がFRしてくれている https://bugs.mysql.com/bug.php?id=81494
  39. 39. mysqldump に注意 • --lock-all-tables は 書き込みがブロックされる • mysqldump するノードは外す必要がある • スレーブがあればスレーブからでも可 39 MasterMaster MasterMaster MasterMaster LBLB mysqldump
  40. 40. 40 SplitBrain 時の挙動
  41. 41. Split Brain とは • クラスターが複数のセットに分断されてしまうこと • どっちを生かすか? • 「過半数を生かす」戦略が一般的 • MGRでは3台以上での構成必須 41 11 22 33 ClientClient 他の2台が 見えなくなった! 自分はリクエストを 受け続けるべき だろうか? 他の2台が 見えなくなった! 自分はリクエストを 受け続けるべき だろうか?
  42. 42. 少数派では更新がブロックされる mysql> SELECT * FROM tbl; +------+ | c1 | +------+ | 0 | +------+ 4 rows in set (0.00 sec) mysql> INSERT INTO tbl VALUES(1); (タイムアウト) Group ReplicationGroup Replication gr03gr03 gr02gr02 gr01gr01 mysql> SELECT MEMBER_HOST,MEMBER_STATE FROM performance_schema.replication_group_members; +-------------+--------------+ | MEMBER_HOST | MEMBER_STATE | +-------------+--------------+ | gr02 | UNREACHABLE | | gr01 | ONLINE | ★ | gr03 | UNREACHABLE | +-------------+--------------+ 3 rows in set (0.00 sec) 遅れたデータ遅れたデータ
  43. 43. 多数派のほうは継続稼動 mysql> SELECT * FROM tbl; +------+ | c1 | +------+ | 2 | +------+ 4 rows in set (0.00 sec) mysql> INSERT INTO tbl VALUES(1); Query OK, 1 row affected (0.00 sec) Group ReplicationGroup Replication gr03gr03 gr02gr02 gr01gr01 mysql> SELECT MEMBER_HOST,MEMBER_STATE FROM performance_schema.replication_group_members; +-------------+--------------+ | MEMBER_HOST | MEMBER_STATE | +-------------+--------------+ | gr02 | ONLINE | | gr03 | ONLINE | +-------------+--------------+ 2 rows in set (0.00 sec)
  44. 44. • サーバの「生きてる」「死んでる」だけ意識すれば良い 44 LBLB• Split Brain を意識した判定が必要 11 22 33
  45. 45. Split Brain を意識した判定 45 mysql> SELECT MEMBER_HOST,MEMBER_STATE FROM performance_schema.replication_group_members; +-------------+--------------+ | MEMBER_HOST | MEMBER_STATE | +-------------+--------------+ | gr02 | UNREACHABLE | | gr01 | ONLINE | | gr03 | UNREACHABLE | +-------------+--------------+ 3 rows in set (0.00 sec) SELECT COUNT(*) / 2 FROM replication_group_members SELECT COUNT(*) FROM replication_group_members WHERE MEMBER_STATE == ‘ONLINE’ < そのノードから見えている、生きているノードが過半数か判定
  46. 46. MGR用 死活監視スクリプト • 中の人(lefred) がスクリプトをすでに作ってくれている • HAProxy と組み合わせて使える 46 https://github.com/lefred/mysql_gr_routing_check
  47. 47. 47 flow control
  48. 48. flow control • ノード間の遅延を最小限にする仕組み • 遅れたノードがほかのノードに「待った」をかける • 閾値の設定 48 mysql> SHOW GLOBAL VARIABLES LIKE '%flow%threshold%'; +----------------------------------------------------+-------+ | Variable_name | Value | +----------------------------------------------------+-------+ | group_replication_flow_control_applier_threshold | 1000 | | group_replication_flow_control_certifier_threshold | 2000 | +----------------------------------------------------+-------+
  49. 49. Certification と Apply 49 11 22 33 UPDATE CertificationCertification http://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/ CertificationCertification ApplyApply OK OK 更新する内容 を伝える 更新する内容 を伝える ApplyApply ApplyApply CertificationCertification
  50. 50. テスト • 3台中1台に向けてベンチマークを流す • ベンチを流しているノードと違うノードでDISK IOを絞る 50 11 22 33 sysbench
  51. 51. テスト結果 51 0 50 100 150 200 250 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 sysbench oltp TPS → 時間 IO制限
  52. 52. テスト結果 52 0 50 100 150 200 250 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 sysbench oltp TPS → 時間 キュー が閾値 に達す るまで の時間 キュー が閾値 に達す るまで の時間
  53. 53. flow control の発動確認 • flow control が発動したことを確かめる方法が見あたらず • member_stats を定期的にモニターしておく? 53 mysql> select * from performance_schema.replication_group_member_stats¥G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier VIEW_ID: 14848273670723157:18 MEMBER_ID: a1c37edb-cd89-11e6-a463-fa163e49d992 COUNT_TRANSACTIONS_IN_QUEUE: 0 COUNT_TRANSACTIONS_CHECKED: 33847 COUNT_CONFLICTS_DETECTED: 0 COUNT_TRANSACTIONS_ROWS_VALIDATING: 16220 TRANSACTIONS_COMMITTED_ALL_MEMBERS: 87e5ed8c-cd83-11e6-bc3c-fa163e83e8e7:1- 47917:1012952-1017941:2017563-2080097 LAST_CONFLICT_FREE_TRANSACTION: 87e5ed8c-cd83-11e6-bc3c-fa163e83e8e7:67719
  54. 54. 本日の内容 54 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 5.導入方法 6.まとめ
  55. 55. STEP1: インストールとユーザ作成 55 • レプリケーションユーザを作成しておく • この時点でbinlogはまだ有効化してはいけない mysql> CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rpl_pass'; mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
  56. 56. STEP2-1:レプリケーション設定 • GTID • log-slave-updates • {master,relay}-log-info-repository=TABLE • binlog-format=row 56 server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW
  57. 57. STEP2-2:Group Replication 設定 57 # Group Replication の設定 transaction_write_set_extraction=XXHASH64 # SELECT UUID() で生成した任意のUUIDを指定 loose-group_replication_group_name="87e5ed8c-cd83-11e6-bc3c-fa163e83e8e7" loose-group_replication_start_on_boot=off # 自分のIPアドレス loose-group_replication_local_address= "172.21.134.26:24901" # すべてのサーバを並べる loose-group_replication_group_seeds= "172.21.134.26:24901,172.21.134.27:24901,172.21.134.28:24901" loose-group_replication_bootstrap_group= off loose-group_replication_single_primary_mode=FALSE loose-group_replication_enforce_update_everywhere_checks= TRUE # サーバ間の通信に利用するネットワークを許可する loose-group_replication_ip_whitelist = 172.21.134.0/23
  58. 58. STEP3:Group Replication 開始 58 mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery'; Query OK, 0 rows affected, 2 warnings (0.02 sec) mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so'; Query OK, 0 rows affected (0,01 sec) mysql> SHOW PLUGINS; | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | | validate_password | ACTIVE | VALIDATE PASSWORD | validate_password.so | +--------------------+--------+-------------------+----------------------+ 46 rows in set (0.01 sec) • group_replication_recovery を設定
  59. 59. STEP3:Group Replication 開始 59 mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery'; Query OK, 0 rows affected, 2 warnings (0.02 sec) mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so'; Query OK, 0 rows affected (0,01 sec) mysql> SHOW PLUGINS; | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | | validate_password | ACTIVE | VALIDATE PASSWORD | validate_password.so | +--------------------+--------+-------------------+----------------------+ 46 rows in set (0.01 sec) • group_replication_recovery を設定内部で使うユーザが作成される CREATE USER '_gr_user'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*7CF5CA9067EC647187EB99FCC27548FBE4839AE3' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT LOCK
  60. 60. STEP4:Group Replication 開始 60 mysql> SET GLOBAL group_replication_bootstrap_group=ON; Query OK, 0 rows affected (0.00 sec) mysql> START GROUP_REPLICATION; Query OK, 0 rows affected (1.76 sec) mysql> SET GLOBAL group_replication_bootstrap_group=OFF; Query OK, 0 rows affected (0.00 sec) • group_replication_bootstrap_group=ON は最初の1台だけ
  61. 61. STEP5:ステータス確認 61 mysql> SELECT * FROM performance_schema.replication_group_members; +---------------------------+----------------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_STATE | +---------------------------+----------------------+-------------+--------------+ | group_replication_applier | 0cdd0b6a-cd84-<snip> | gr02 | ONLINE | | group_replication_applier | 1edf2e1d-cd83-<snip> | gr01 | ONLINE | | group_replication_applier | a1c37edb-cd89-<snip> | gr03 | ONLINE | +---------------------------+----------------------+-------------+--------------+ 3 rows in set (0.00 sec)
  62. 62. MGR 制限事項 • InnoDB のみサポート • PK or UNIQUE キーが必須 • GTID + ROW ベースレプリケーション • トランザクション分離レベルはREAD-COMMITED • 複数の同じテーブルに対するDDLとDMLの同時複数ノード実行はサ ポート外 62 ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin
  63. 63. 本日の内容 63 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 5.導入方法 6.まとめ
  64. 64. Galera Cluster、従来構成 との比較表 Group Replication Galera Cluster 通常のマスター昇格 1 マルチライター 対応 対応 非対応 2 データ同期の仕組み GTID Replication base wsrepl GTID or 非GTID 3 バイナリログ 必須 必須ではない 必須 4 ストレージエンジン InnoDB のみ InnoDB のみ 制限なし 5 ノード間の ロック仕組み 楽観的ロック (First Commit Wins) 楽観的ロック (First Commit Wins) 競合しない ※ マルチライターではない 6 AutoIncr 衝突回避 ○ 自動 ○ 自動 - 7 自動リトライ ○ × × 7 クラスタリングや フェイルオーバ機構 ビルドイン(XCom) ビルドイン (Galera) ビルドインされない ※ 自分で用意 8 自動リカバリ(差分) ○ ○ (IST) ○ レプリケーション 9 自動リカバリ(全体) × ○ (SST) × 10 SplitBrain 対応 ○ 対応 ○ 対応 × 自分で考える 11 ステータス確認 performance_schema GLOBAL STATUS performance_schema or SHOW 12 提供形態 ○ プラグイン △ 別製品。互換性はあり。 - 13 最新バージョン 5.7 GA Galera 5.7 GA Percona Cluster 5.7 GA MariaDB Cluster 10.1 GA MySQL 5.7 GA Percona 5.7 GA MariaDB 10.1 GA 64
  65. 65. 参考資料 • Oracle社 2017年1月25日 MySQL Tech Tour講演資料 MySQLの新しい高可用性構成 MySQLグループ・レプリケーション • https://www-jp.mysql.com/why- mysql/presentations/mysql-group-replication-201701-ja/ 65
  66. 66. まだ試してないこと • DDLの流し方、ベストプラクティス • パフォーマンス • ノードを増やしたときの性能劣化度合い • Galeraとの比較。Galera より速いらしい 66 http://mysqlhighavailability.com/ performance-evaluation-mysql-5-7-group-replication/ より引用
  67. 67. 67 ~ ご案内 ~
  68. 68. ご案内 68 • MySQL Casual Slack • https://t.co/QobukOxvUw • 日本MySQL ユーザ会 ML • http://mysql.gr.jp/ml.html
  69. 69. まとめ • Group Replication 5.7 で GAになったよヾ(@^▽^@)ノ • マルチライター盛り上げていきましょう 69
  70. 70. 70 Enjoy MySQL

×