在上一篇文章中，我們大概介紹了Mysql Group Replication的構架及叢集搭建步驟。那麼我們知道，一組優秀的叢集環境有一個很必要的特性，那就是可拓展性。Group Replication的拓展性怎麼樣呢？我們設定如下幾個場景，來看看Group Replicaiton是否方便拓展：

1. 總執行的事務量較少，而且所有的binlog都保留完整。
2. 總事務量較少，binlog只保留部分。
3. 總事務量很大，binlog保留完整。
4. 總事務量很大，binlog只保留部分。

我們在對以上幾種場景進行分析

1. 總事務量較少，binlog保留完整。那麼我們可以直接應用所有binlog，來建立一個和現有環境相同的例項。

2. 總事務量較少，binlog保留部分。此場景中binlog丟失，無法應用所有binlog來建立一個和現有環境相同的例項。那麼我們要得到一個和現有環境相同的例項，只有複製一個現有環境中的例項，然後再將這個例項新增到叢集。複製的方法我能想到的有如下幾種：

   • mysqldump
   • xdbbackup
3. 總事務量較多，binlog保留完整。我們可以和第一種環境一樣，應用所有binlog來建立新例項。但是事務較多應用binlog需要非常多的時間。為了提高效率，我們還是採用複製例項的方式來建立新例項。
4. 總事務較多，binlog只保留部分。這個場景和第二個場景差不多，我們也只能採用複製例項的方式來建立新的例項。

經過分析總我們有兩種方式來向Group Replication叢集中加入新節點：
- 直接加入
- 複製例項後再加入

接下來逐個看一下怎麼加入

節點資訊

servername	ip	port	group port
server01	127.0.0.1	3306	6606
server02	127.0.0.1	3307	6607
server03	127.0.0.1	3308	6608
==server04==	==127.0.0.1==	==3309==	==6609==

直接加入

安裝mysql5.7.15,並安裝Group Replication

配置引數。

[my4.cnf]

[mysqld]
#base config
server-id = 4
basedir=/usr/local/mysql5.7/
datadir=/usr/local/mysql5.7/data03
user=mysql
explicit_defaults_for_timestamp
socket=mysql4.sock
port = 3309

#binlog
log-bin=mysql-bin
binlog-format = ROW
gtid-mode = ON
enforce-gtid-consistency = ON
log-slave-updates = ON
master-info-repository = TABLE
relay-log-info-repository = TABLE
binlog-checksum = NONE

#group replication
transaction-write-set-extraction = XXHASH64
group_replication_start_on_boot = OFF
group_replication_bootstrap_group = OFF
group_replication_group_name = 0c6d3e5f-90e2-11e6-802e-842b2b5909d6
group_replication_local_address = '127.0.0.1:6609'
group_replication_group_seeds = '127.0.0.1:6606,127.0.0.1:6607,127.0.0.1:6609'

啟動mysql

[server04]

./bin/mysqld --defaults-file=/usr/local/mysql5.7/my4.cnf

加入叢集

修改原有節點member資訊

[server1]

mysql> set global group_replication_group_seeds='127.0.0.1:6607,127.0.0.1:6608,127.0.0.1:6609';

[server2]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6608,127.0.0.1:6609';

[server3]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6607,127.0.0.1:6609';

在新節點上建立複製使用者

mysql>SET SQL_LOG_BIN=0;
mysql>CREATE USER [email protected]'%';
mysql>GRANT REPLICATION SLAVE ON *.* TO mysql>[email protected]'%' IDENTIFIED BY 'rpl_pass';
mysql>FLUSH PRIVILEGES;
mysql>SET SQL_LOG_BIN=1;

啟動新節點的group_replication

mysql>CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery';
mysql>start group_replication;

檢視叢集節點狀態

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 0aab37dc-911c-11e6-ab03-842b2b5909d6 | mser01      |        3308 | ONLINE       |
| group_replication_applier | 18772df6-91ee-11e6-a00e-842b2b5909d6 | mser01      |        3309 | ONLINE       |
| group_replication_applier | a876d35e-9110-11e6-a365-842b2b5909d6 | mser01      |        3306 | ONLINE       |
| group_replication_applier | b34df071-911a-11e6-9796-842b2b5909d6 | mser01      |        3307 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
4 rows in set (0.00 sec)

可以發現[server4]已經成功加入到叢集。

注：如果在原有叢集中建立複製使用者時沒有將SQL_LOG_BIN關閉，那麼在新節點中就不需要執行建立複製使用者這個步驟。

複製例項後加入

安裝mysql5.7.15,並安裝Group Replication

配置引數。

[my4.cnf]

[mysqld]
#base config
server-id = 4
basedir=/usr/local/mysql5.7/
datadir=/usr/local/mysql5.7/data03
user=mysql
explicit_defaults_for_timestamp
socket=mysql4.sock
port = 3309

#binlog
log-bin=mysql-bin
binlog-format = ROW
gtid-mode = ON
enforce-gtid-consistency = ON
log-slave-updates = ON
master-info-repository = TABLE
relay-log-info-repository = TABLE
binlog-checksum = NONE

#group replication
transaction-write-set-extraction = XXHASH64
group_replication_start_on_boot = OFF
group_replication_bootstrap_group = OFF
group_replication_group_name = 0c6d3e5f-90e2-11e6-802e-842b2b5909d6
group_replication_local_address = '127.0.0.1:6609'
group_replication_group_seeds = '127.0.0.1:6606,127.0.0.1:6607,127.0.0.1:6609'

複製例項並加入叢集

mysqldump

匯出資料

在現有Group Replication叢集中找一個節點將所有資料使用mysqldump匯出：

bin/mysqldump -uroot -p111111 -h127.0.0.1 -P3308 -x --triggers --routines --events --all-databases --master-data=2 > /tmp/bobo.sql

注：1、在測試過程中使用–single-transaction會報如下錯誤：


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)


2、–all-database是必須的麼？這個還要研究一下

在新節點執行sql檔案

[[email protected] mysql5.7]# bin/mysql -uroot -p111111 -h127.0.0.1 -P3309 < /tmp/bobo.sql 
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

可以看到語句執行時有1840錯誤，這裡只需要重新設定一下master就可以了：

[root@mser01 mysql5.7]# bin/mysql -uroot -p111111 -h127.0.0.1 -P3309 -e 'reset master'

再次執行bobo.sql語句就能執行成功了。

注：當你執行bobo.sql語句時在日誌中能看到如下日誌，那麼就說明新節點GTID初始的值設定成功，在start group_replication是就能順利開啟了：

2016-10-17T07:12:56.281059Z 5 [Note] @@GLOBAL.GTID_PURGED was changed from '' to '0aab37dc-911c-11e6-ab03-842b2b5909d6:1,
0c6d3e5f-90e2-11e6-802e-842b2b5909d6:1-37,
a876d35e-9110-11e6-a365-842b2b5909d6:1-3,
b34df071-911a-11e6-9796-842b2b5909d6:1'.
2016-10-17T07:12:56.281075Z 5 [Note] @@GLOBAL.GTID_EXECUTED was changed from '' to '0aab37dc-911c-11e6-ab03-842b2b5909d6:1,
0c6d3e5f-90e2-11e6-802e-842b2b5909d6:1-37,
a876d35e-9110-11e6-a365-842b2b5909d6:1-3,
b34df071-911a-11e6-9796-842b2b5909d6:1'.

修改原有節點member資訊

[server1]

mysql> set global group_replication_group_seeds='127.0.0.1:6607,127.0.0.1:6608,127.0.0.1:6609';

[server2]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6608,127.0.0.1:6609';

[server3]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6607,127.0.0.1:6609';

加入Group Replication叢集

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.15 sec)

mysql> start group_replication;
Query OK, 0 rows affected (2.44 sec)

在日誌中出現類似如下資訊就說明加入成功了：

2016-10-17T07:14:12.469000Z 0 [Note] Plugin group_replication reported: 'This server was declared online within the replication group'

檢視叢集資訊

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 0aab37dc-911c-11e6-ab03-842b2b5909d6 | mser01      |        3308 | ONLINE       |
| group_replication_applier | 13a2f2e9-943f-11e6-b910-842b2b5909d6 | mser01      |        3309 | ONLINE       |
| group_replication_applier | a876d35e-9110-11e6-a365-842b2b5909d6 | mser01      |        3306 | ONLINE       |
| group_replication_applier | b34df071-911a-11e6-9796-842b2b5909d6 | mser01      |        3307 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
4 rows in set (0.00 sec)

xtrabackup

安裝xtrabackup

備份資料庫

innobackupex --defaults-file=/usr/local/mysql5.7/my2.cnf --user='root' --password='111111' --socket=/usr/local/mysql5.7/data02/mysql2.sock /tmp/backup/

執行之後可以看到在/tmp/backup中有一個2016-10-17_15-52-11資料夾，這個資料夾就是備份檔案。並且在資料夾中可以看到binlog的相關資訊

[[email protected] 2016-10-17_15-52-11]# cat xtrabackup_binlog_info 
mysql-bin.000009    1198    0aab37dc-911c-11e6-ab03-842b2b5909d6:1,
0c6d3e5f-90e2-11e6-802e-842b2b5909d6:1-47,
a876d35e-9110-11e6-a365-842b2b5909d6:1-3,
b34df071-911a-11e6-9796-842b2b5909d6:1

還原資料庫

將2016-10-17_15-52-11資料夾拷貝到/usr/local/mysql5.7中命令為data04,並修改使用者組：

[root@mser01 mysql5.7]# cp -r /tmp/backup/2016-10-17_15-52-11/  ./data04
[root@mser01 mysql5.7]# chown -R mysql:mysql data04/

啟動新節點

[server04]

./bin/mysqld --defaults-file=/usr/local/mysql5.7/my4.cnf

修改原有節點member資訊

[server1]

mysql> set global group_replication_group_seeds='127.0.0.1:6607,127.0.0.1:6608,127.0.0.1:6609';

[server2]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6608,127.0.0.1:6609';

[server3]

mysql> set global group_replication_group_seeds='127.0.0.1:6606,127.0.0.1:6607,127.0.0.1:6609';

加入叢集

mysql> set @@GLOBAL.GTID_PURGED='0aab37dc-911c-11e6-ab03-842b2b5909d6:1, 0c6d3e5f-90e2-11e6-802e-842b2b5909d6:1-47, a876d35e-9110-11e6-a365-842b2b5909d6:1-3, b34df071-911a-11e6-9796-842b2b5909d6:1';
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
mysql> reset master;
Query OK, 0 rows affected (0.07 sec)

mysql> set @@GLOBAL.GTID_PURGED='0aab37dc-911c-11e6-ab03-842b2b5909d6:1, 0c6d3e5f-90e2-11e6-802e-842b2b5909d6:1-47, a876d35e-9110-11e6-a365-842b2b5909d6:1-3, b34df071-911a-11e6-9796-842b2b5909d6:1';
Query OK, 0 rows affected (0.01 sec)

mysql> start group_replication;
Query OK, 0 rows affected (2.01 sec)

注：因為是整庫備份，所有使用者資訊都完整儲存可以不使用CHANGE MASTER語句。

在日誌中出現類似如下資訊就說明加入成功了：

2016-10-17T07:14:12.469000Z 0 [Note] Plugin group_replication reported: 'This server was declared online within the replication group'

檢視叢集資訊

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 0aab37dc-911c-11e6-ab03-842b2b5909d6 | mser01      |        3308 | ONLINE       |
| group_replication_applier | 13a2f2e9-943f-11e6-b910-842b2b5909d6 | mser01      |        3309 | ONLINE       |
| group_replication_applier | a876d35e-9110-11e6-a365-842b2b5909d6 | mser01      |        3306 | ONLINE       |
| group_replication_applier | b34df071-911a-11e6-9796-842b2b5909d6 | mser01      |        3307 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
4 rows in set (0.00 sec)

總結

從上面三個例子來對比：
1、保留所有binlog直接加入配置最簡單方便，出現問題的概率也比較小，但是對於資料量達到一定程度時，直接加入需要消耗的時間會相當長。
2、使用mysqldump，在binlog不全時十分有用，但是因為mysqldump匯入資料時實際上也是執行語句，時間上並不能提高很多。而且在匯出資料時需要鎖表（目前single-transcation模式下未測試通過），會影響業務的正常執行。
3、使用xtrabackup備份還原，此方法效率最高，而且xtrabackup備份innodb引擎的表時不會鎖表，不影響正常使用。但是相對於前面兩種方式xtrabackup更佔磁碟空間。

思考

現有的普通複製場景是否可以轉換成Group Replicaiton呢？下一篇將針對這個問題進行測試。