MySQL Group Replication增加节点

最新推荐文章于 2024-04-11 21:44:30 发布

BOBO_Free

最新推荐文章于 2024-04-11 21:44:30 发布

阅读量3.5k

点赞数 2

分类专栏： Mysql 文章标签： mysql GR 集群

本文链接：https://blog.csdn.net/hubo890224/article/details/52839855

版权

Mysql 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

在上一篇文章中，我们大概介绍了Mysql Group Replication的构架及集群搭建步骤。那么我们知道，一组优秀的集群环境有一个很必要的特性，那就是可拓展性。Group Replication的拓展性怎么样呢？我们设定如下几个场景，来看看Group Replicaiton是否方便拓展：

总执行的事务量较少，而且所有的binlog都保留完整。
总事务量较少，binlog只保留部分。
总事务量很大，binlog保留完整。
总事务量很大，binlog只保留部分。

我们在对以上几种场景进行分析

总事务量较少，binlog保留完整。那么我们可以直接应用所有binlog，来创建一个和现有环境相同的实例。
总事务量较少，binlog保留部分。此场景中binlog丢失，无法应用所有binlog来创建一个和现有环境相同的实例。那么我们要得到一个和现有环境相同的实例，只有复制一个现有环境中的实例，然后再将这个实例添加到集群。复制的方法我能想到的有如下几种：
- mysqldump
- xdbbackup
总事务量较多，binlog保留完整。我们可以和第一种环境一样，应用所有binlog来创建新实例。但是事务较多应用binlog需要非常多的时间。为了提高效率，我们还是采用复制实例的方式来创建新实例。
总事务较多，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呢？下一篇将针对这个问题进行测试。

BOBO_Free

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
2
评论
MySQL Group Replication增加节点

在上一篇文章中，我们大概介绍了Mysql Group Replication的构架及集群搭建步骤。那么我们知道，一组优秀的集群环境有一个很必要的特性，那就是可拓展性。Group Replication的拓展性怎么样呢？我们设定如下几个场景，来看看Group Replicaiton是否方便拓展：总执行的事务量较少，而且所有的binlog都保留完整。总事务量较少，binlog只保留部分。总事务量很
复制链接

扫一扫