MySQL Group Replication增加节点

在上一篇文章中,我们大概介绍了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

(步骤见上一篇)http://blog.csdn.net/hubo890224/article/details/52816670

配置参数。

[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 rpl_user@'%';
mysql>GRANT REPLICATION SLAVE ON *.* TO mysql>rpl_user@'%' 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

(步骤见上一篇)http://blog.csdn.net/hubo890224/article/details/52816670

配置参数。

[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文件
[root@mser01 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

http://blog.csdn.net/hubo890224/article/details/50513904

备份数据库
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的相关信息

[root@mser01 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呢?下一篇将针对这个问题进行测试。

你可能感兴趣的:(Mysql)