（続）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 Replication 9

5.7 GAとは何だったのか履歴 • 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 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ

高可用性ソリューション • マルチライター構成が組める • 高可用性ソリューション • 性能向上を主目的としたものではない 14 Master Master Master Master Master Master Master Master Master Master 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 Master Master Master Master Master Master Master Master Master Master • 障害を自動検知し、データ同期対象から切り離す • 復旧時には差分を自動的にリカバリ

構成パターン 16 Master Master Read only Master Read only Master Read only Master Read only Master Single Primary • 従来のマスター/スレーブに相当 • 任意の1台のみWriteが可能になる Master Master Master Master Master Master Multi Writer 構成 • 全部に読み書き • 最大限の可用性 group_replication_single_primary_mode=FALSE group_replication_single_primary_mode=TRUE

本日の内容 17 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 5. flow control 6. 導入方法 7. まとめ

通常レプリにGroup Replication レイヤーが追加 18 引用元：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: 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

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

スレーブをぶらさげてもOK 21 Async Slave Async Slave Async Slave Async Slave Group Replication Write Write Read Read

スレーブのマスターの切り替えも簡単 22 Async Slave Async Slave Async Slave Async Slave Group Replication Write Write Read Read

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

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

理由 • たくさんのDBを管理していると・・・ • なるべく同じ構成で管理したい • マスター・スレーブですらツライ • DBサーバ以外のサーバ増やしたくない • MHAのmanager、MySQL fabric など • なるべくビルドインされたものを使いたい 25

理由 • サーバの「生きてる」「死んでる」だけ意識すれば良い • ロードバランサの運用はツラくない（はず） • Webサーバでたくさん使ってるよね？ 26 Master Master Master Master Master Master LB LB

本日の内容 27 1. 何ができるのか 2. 仕組み 3. ロックの挙動 4. 障害時の挙動 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 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 - トランザクション１のロック開放待ち 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 構成の場合 時間 行の値 トランザクション１ トランザクション２ 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) トランザクション１のロック開放待ち 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 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

Group Replication 構成の場合 31 時間 行の値 トランザクション１ on ノード1 トランザクション２ 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 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 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='', 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='samitani-gr02.db.ssk.ynwm.yahoo.co.jp', master_port= 3306, master_log_file='', master_log_pos=4, master_bind=''. New state master_host='', 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 Master Master Master Master Master Master LB LB mysqldump

40 SplitBrain 時の挙動

Split Brain とは • クラスターが複数のセットに分断されてしまうこと • どっちを生かすか？ • 「過半数を生かす」戦略が一般的 • MGRでは3台以上での構成必須 41 1 1 2 2 3 3 Client Client 他の２台が 見えなくなった！ 自分はリクエストを 受け続けるべき だろうか？ 他の２台が 見えなくなった！ 自分はリクエストを 受け続けるべき だろうか？

少数派では更新がブロックされる mysql> SELECT * FROM tbl; +------+ | c1 | +------+ | 0 | +------+ 4 rows in set (0.00 sec) mysql> INSERT INTO tbl VALUES(1); (タイムアウト) Group Replication Group Replication gr03 gr03 gr02 gr02 gr01 gr01 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 | +------+ 4 rows in set (0.00 sec) mysql> INSERT INTO tbl VALUES(1); Query OK, 1 row affected (0.00 sec) Group Replication Group Replication gr03 gr03 gr02 gr02 gr01 gr01 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 LB LB • Split Brain を意識した判定が必要 1 1 2 2 3 3

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 1 1 2 2 3 3 UPDATE Certification Certification http://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/ Certification Certification Apply Apply OK OK 更新する内容 を伝える 更新する内容 を伝える Apply Apply Apply Apply Certification Certification

テスト • 3台中1台に向けてベンチマークを流す • ベンチを流しているノードと違うノードでDISK IOを絞る 50 1 1 2 2 3 3 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_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 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 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=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

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

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 を設定

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

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

STEP5：ステータス確認 61 mysql> SELECT * FROM performance_schema.replication_group_members; +---------------------------+----------------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_STATE | +---------------------------+----------------------+-------------+--------------+ | group_replication_applier | 0cdd0b6a-cd84- | gr02 | ONLINE | | group_replication_applier | 1edf2e1d-cd83- | gr01 | ONLINE | | group_replication_applier | a1c37edb-cd89- | 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 1.何ができるのか 2.仕組み 3.ロックの挙動 4.障害時の挙動 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 GA Percona Cluster 5.7 GA MariaDB Cluster 10.1 GA MySQL 5.7 GA Percona 5.7 GA MariaDB 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/ より引用

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