Upload
satoshi-mitani
View
947
Download
9
Embed Size (px)
Citation preview
(続)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
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘A’
WHERE pk = 1
UPDATE tSET col = ‘A’
WHERE pk = 1
自動リカバリー
15
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
• 障害を自動検知し、データ同期対象から切り離す
• 復旧時には差分を自動的にリカバリ
構成パターン
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
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: <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
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘A’
WHERE pk = 1
UPDATE tSET col = ‘A’
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
AsyncSlaveAsyncSlave
Group Replication
WriteWrite
ReadRead
スレーブのマスターの切り替えも簡単
22
AsyncSlaveAsyncSlave
AsyncSlaveAsyncSlave
Group Replication
WriteWrite
ReadRead
23
MGRが今後スタンダードにな(ってほしいな|るはず)
理由
• たくさんのDBを管理していると・・・
24
理由
• たくさんのDBを管理していると・・・
• なるべく同じ構成で管理したい
• マスター・スレーブですらツライ
• DBサーバ以外のサーバ増やしたくない
• MHAのmanager、MySQL fabric など
• なるべくビルドインされたものを使いたい
25
理由
• サーバの「生きてる」「死んでる」だけ意識すれば良い
• ロードバランサの運用はツラくない(はず)
• 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 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)
非 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ノード(マスター)に対してのみ実行可
• ロックが競合した場合、後続は「待つ」
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
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
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='<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
MasterMaster MasterMaster MasterMaster
LBLB
mysqldump
40
SplitBrain 時の挙動
Split Brain とは
• クラスターが複数のセットに分断されてしまうこと
• どっちを生かすか?
• 「過半数を生かす」戦略が一般的
• MGRでは3台以上での構成必須
41
11 22 33
ClientClient
他の2台が見えなくなった!
自分はリクエストを受け続けるべき
だろうか?
他の2台が見えなくなった!
自分はリクエストを受け続けるべき
だろうか?
少数派では更新がブロックされる
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)
遅れたデータ遅れたデータ
多数派のほうは継続稼動
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
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
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=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 を設定
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-<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
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 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/ より引用
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