MySQL Group Replication - MySQL Casual Talk vol.10

（続）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.11 InnoDB Tablespace encryption

• 5.7.12 X Protocol, MySQL Document Store

• 5.7.17 new! Group Replication

9


• 5.7.11 InnoDB Tablespace encryption

• 5.7.12 X Protocol, MySQL Document Store

• 5.7.17 new! Group Replication

10

自己紹介

• 三谷智史（@mita2）

• MySQL DBA

• 最近の興味

• OpenStack Trove

• Percona XtraDB Cluster

• Group Replication

11

本日の内容

12

1.何ができるのか

2.仕組み

3.ロックの挙動

4.障害時の挙動

5. flow control

6.導入方法

7.まとめ

本日の内容

13


2.仕組み



5. flow control

6.導入方法

7.まとめ

高可用性ソリューション

• マルチライター構成が組める

• 高可用性ソリューション

• 性能向上を主目的としたものではない

14

MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster

UPDATE tSET col = ‘B’

WHERE pk = 2


WHERE pk = 2

UPDATE tSET col = ‘A’

WHERE pk = 1


WHERE pk = 1

自動リカバリー

15


• 障害を自動検知し、データ同期対象から切り離す

• 復旧時には差分を自動的にリカバリ

構成パターン

16

MasterMasterRead only

MasterRead only

MasterRead only

MasterRead only

Master

Single Primary• 従来のマスター/スレーブに相当• 任意の1台のみWriteが可能になる

MasterMaster MasterMaster MasterMaster

Multi Writer 構成• 全部に読み書き• 最大限の可用性

group_replication_single_primary_mode=FALSEgroup_replication_single_primary_mode=TRUE

本日の内容

17


2.仕組み



5. flow control

6.導入方法

7.まとめ

通常レプリにGroup Replication レイヤーが追加

18引用元：https://www.percona.com/live/data-performance-conference-2016/content/high-availability-using-mysql-group-replication

https://www.percona.com/live/data-performance-conference-2016/content/high-availability-using-mysql-group-replication

レプリケーション

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



WHERE pk = 2


WHERE pk = 2


WHERE pk = 1


WHERE pk = 1

Full GTID Support

20

• どこに書いても同じUUIDのGTIDが発行される• group_replication_group_name で指定したものがUUIDになる

aaa-bbb-111:10 ⇒ pk=1 col=Aaaa-bbb-111:20 ⇒ pk=2 col=Baaa-bbb-111:10 ⇒ pk=1 col=Aaaa-bbb-111:20 ⇒ pk=2 col=B

binlog

スレーブをぶらさげてもOK

21

AsyncSlaveAsyncSlave


Group Replication

WriteWrite

ReadRead

スレーブのマスターの切り替えも簡単

22



Group Replication

WriteWrite

ReadRead

23

MGRが今後スタンダードにな(ってほしいな|るはず)

理由

• たくさんのDBを管理していると・・・

24

理由

• たくさんのDBを管理していると・・・

• なるべく同じ構成で管理したい

• マスター・スレーブですらツライ

• DBサーバ以外のサーバ増やしたくない

• MHAのmanager、MySQL fabric など

• なるべくビルドインされたものを使いたい

25

理由

• サーバの「生きてる」「死んでる」だけ意識すれば良い

• ロードバランサの運用はツラくない（はず）

• Webサーバでたくさん使ってるよね？

26


LBLB

本日の内容

27


2.仕組み



5. flow control

6.導入方法

7.まとめ

非 Group Replication 構成の場合時間行の値トランザクション１トランザクション２

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


mysql> UPDATE grplt.tbl SET col1 = 10,

who_update = ‘B' WHERE pk = 1;T3 - トランザクション１のロック開放待ち

T4 A mysql> COMMIT;Query OK, 0 rows affected (0.00 sec)

トランザクション１のロック開放待ち

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)

非 Group Replication 構成の場合時間行の値トランザクション１トランザクション２


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


mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1;

T3 - トンラザクション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)

• 更新は１ノード（マスター）に対してのみ実行可

• ロックが競合した場合、後続は「待つ」

• 更新は１ノード（マスター）に対してのみ実行可

• ロックが競合した場合、後続は「待つ」

Group Replication 構成の場合

30

時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2




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


(ノード１の更新内容が伝わってくる）

T4 A mysql> COMMIT;

ERROR 1180 (HY000):

Got error 149 during COMMIT

Group Replication 構成の場合

31

時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2




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


T4 A mysql> COMMIT;

ERROR 1180 (HY000):

Got error 149 during COMMIT

• 異なるノードでロックが競合した場合、「先勝ち」

• 同じノードであれば、非GR構成と同じ挙動

• ロックの挙動を変えたくなければ、Single-Primary で運用

• 異なるノードでロックが競合した場合、「先勝ち」

• 同じノードであれば、非GR構成と同じ挙動

• ロックの挙動を変えたくなければ、Single-Primary で運用

本日の内容

32


2.仕組み



5.導入方法

6.まとめ

ノードダウン後の挙動

• 自動的に同期対象から外れる

• キャッチアップするまでは「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

[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=''.

• リカバリ開始

• リカバリ完了

すでにbinlogがなくなってるパターン

ちなみに、

• Galera では State Snapshot Transferで自動全コピー

• 内部的にはxtrabackup or mysqldump or rsync

35

すでに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

1. 生きてるノードからmysqldumpする

2. 壊れたノードに投入

3. START GROUP REPLICATION

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

mysqldump に注意

• --lock-all-tables は書き込みがブロックされる

• mysqldump するノードは外す必要がある

• スレーブがあればスレーブからでも可

39


LBLB

mysqldump

40

SplitBrain 時の挙動

Split Brain とは

• クラスターが複数のセットに分断されてしまうこと

• どっちを生かすか？

• 「過半数を生かす」戦略が一般的

• MGRでは3台以上での構成必須

41

11 22 33

ClientClient

他の２台が見えなくなった！

自分はリクエストを受け続けるべき

だろうか？

他の２台が見えなくなった！

自分はリクエストを受け続けるべき

だろうか？

少数派では更新がブロックされる

mysql> SELECT * FROM tbl;

+------+

| c1 |

+------+

| 0 |

+------+


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)

遅れたデータ遅れたデータ

多数派のほうは継続稼動

mysql> SELECT * FROM tbl;

+------+

| c1 |

+------+

| 2 |

+------+


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

LBLB• Split Brain を意識した判定が必要

11 22 33

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’

<

そのノードから見えている、生きているノードが過半数か判定

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%';+----------------------------------------------------+-------+| Variable_name | Value |+----------------------------------------------------+-------+| group_replication_flow_control_applier_threshold | 1000 || group_replication_flow_control_certifier_threshold | 2000 |+----------------------------------------------------+-------+

Certification と Apply

49

11 22 33

UPDATE

Certific

atio

nCertific

atio

nhttp://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/

Certific

atio

nCertific

atio

n

Apply

Apply

OKOK

更新する内容を伝える

更新する内容を伝える

Apply

Apply

Apply

Apply

Certific

atio

nCertific

atio

n

テスト

• 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 65 67 69 71 73 75 77 79 81

sysbench oltp TPS

→ 時間

IO制限

テスト結果

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

→ 時間

キューが閾値に達するまでの時間

キューが閾値に達するまでの時間

flow control の発動確認

• flow control が発動したことを確かめる方法が見あたらず

• member_stats を定期的にモニターしておく？

53

mysql> select * from performance_schema.replication_group_member_stats¥G*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applierVIEW_ID: 14848273670723157:18

MEMBER_ID: a1c37edb-cd89-11e6-a463-fa163e49d992

COUNT_TRANSACTIONS_IN_QUEUE: 0COUNT_TRANSACTIONS_CHECKED: 33847COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 16220TRANSACTIONS_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


2.仕組み



5.導入方法

6.まとめ

STEP1: インストールとユーザ作成

55

• レプリケーションユーザを作成しておく

• この時点でbinlogはまだ有効化してはいけない

mysql> CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rpl_pass';

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

STEP2-1：レプリケーション設定

• GTID

• log-slave-updates

• {master,relay}-log-info-repository=TABLE

• binlog-format=row

56

server_id=1gtid_mode=ONenforce_gtid_consistency=ONmaster_info_repository=TABLErelay_log_info_repository=TABLEbinlog_checksum=NONElog_slave_updates=ONlog_bin=binlogbinlog_format=ROW

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= offloose-group_replication_single_primary_mode=FALSEloose-group_replication_enforce_update_everywhere_checks= TRUE

# サーバ間の通信に利用するネットワークを許可する

loose-group_replication_ip_whitelist = 172.21.134.0/23

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

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

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台だけ

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)

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


2.仕組み



5.導入方法

6.まとめ

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 GAPercona Cluster 5.7 GAMariaDB Cluster 10.1 GA

MySQL 5.7 GAPercona 5.7 GAMariaDB 10.1 GA 64

参考資料

• Oracle社 2017年1月25日 MySQL Tech Tour講演資料MySQLの新しい高可用性構成MySQLグループ・レプリケーション

• https://www-jp.mysql.com/why-mysql/presentations/mysql-group-replication-201701-ja/

65

まだ試してないこと

• DDLの流し方、ベストプラクティス

• パフォーマンス

• ノードを増やしたときの性能劣化度合い

• Galeraとの比較。Galera より速いらしい

66

http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/ より引用

http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

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

MySQL Group Replication - MySQL Casual Talk vol.10

Engineering