引言
MySQL Group Replication(简称MGR)是MySQL官方于2016年12月份推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用,高扩展、高可靠的MySQL集群服务。MGR是MySQL数据库未来发展的一个重要方向。
场景描述
| 操作系统 | MySQL版本 |
|---|---|
| CentOS Linux release 7.3.1611 | MySQL5.7.20 二进制 |
-
ip地址规划
| IP地址 | hosts | port |
|---|---|---|
| 192.168.74.134 | mgr-node1.up.com | 330623306 |
| 192.168.74.135 | mgr-node2.up.com | 330623306 |
| 192.168.74.136 | mgr-node3.up.com | 330623306 |
一个已经运行很久的MGR集群,以single-master模式运行(单主模式),binlog过期策略为7天。
- 参数设置
| Key | Value |
|---|---|
| enforce_gtid_consistency | ON |
| master_info_repository | TABLE |
| relay_log_info_repository | TABLE |
| binlog_checksum | NONE |
| log_slave_updates | ON |
| binlog_format | ROW |
| ==expire_logs_days== | ==7== |
- 需求描述
因为不可抗力的因素mgr-node3.up.com节点永久性的down 并且无法恢复,或者mgr-node3.up.com宕机超过时间7day,
或需要快速添加节点。那么改如何快速添加或扩容呢?
猜想
1.如果这个问题发送在Percona XtraDB Cluster(pxc)或者Mariadb Galera Cluster解决方案是通过SST(全量)或者IST(增量)来实现,那么MGR是否SST或者IST的方案呢?
2.假设MGR也是通过SST或者IST来的解决方案入 MGR是否使用MySQLdump 或者rsync来获得一份全量?
3.假设是通过MySQLdump来实现传递增量。是否可以用xtrabackup来替换呢?
根据上述的猜想和假设来求证,如何优雅的添加MGR节点。
验证
猜想一 在MySQL官方文档中没有找到关于SST或IST的描述,既然官方文档没有写那么在实验环境中是否能模拟出来。
-实验
在mgr-node1.up.com主节点创建一张表
"root@localhost:mysql3306.sock [aa]>show create table aa;
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+
| aa | CREATE TABLE `aa` (
`id` int(11) NOT NULL,
`name` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+
"root@localhost:mysql3306.sock [aa]>select * from aa;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | a |
| 3 | a |
| 4 | a |
| 5 | a |
+----+------+
5 rows in set (0.00 sec)
加入新的节点mgr-node4.up.com并初始化,开启现有环境所有节点的general_log观察general的输出
mgr-node1.up.com 节点
2017-11-16T15:38:52.818216Z 32 Connect slave@mgr-node4.up.com on using TCP/IP
2017-11-16T15:38:52.829195Z 32 Query SELECT UNIX_TIMESTAMP()
2017-11-16T15:38:52.829836Z 32 Query SELECT @@GLOBAL.SERVER_ID
2017-11-16T15:38:52.835000Z 32 Query SET @master_heartbeat_period= 30000001024
2017-11-16T15:38:52.842449Z 32 Query SET @master_binlog_checksum= @@global.binlog_checksum
2017-11-16T15:38:52.843032Z 32 Query SELECT @master_binlog_checksum
2017-11-16T15:38:52.843355Z 32 Query SELECT @@GLOBAL.GTID_MODE
2017-11-16T15:38:52.843529Z 32 Query SELECT @@GLOBAL.SERVER_UUID
2017-11-16T15:38:52.843726Z 32 Query SET @slave_uuid= '5d03ede3-cae1-11e7-9319-000c299354d5'
2017-11-16T15:38:52.844093Z 32 Binlog Dump GTID Log: '' Pos: 4 GTIDs: ''
2017-11-16T15:39:52.972984Z 33 Connect slave@mgr-node4.up.com on using TCP/IP
从general_log中找到了蛛丝马迹,目前版本的MGR,不支持SST或IST。实现的方式是根据GTID的方式来实现的。
同时在general_log中也发现,目前版本的MGR也不支持MySQLdump或者rsync方式来给新加入的节点传递全量。如果binlog被清空的话 则显示为空 新的节点无法加入集群但
"root@localhost:mysql3306.sock [aa]>start group_replication;
提示成功
正确姿势
1.首先需要手动在MGR集群中获得一致性备份。
2.初始化新节点,并应用备份。
注意如下操作 否则无法正常添加到集群
"root@localhost:mysql3306.sock [aa]>reset master;
Query OK, 0 rows affected (0.00 sec)
"root@localhost:mysql3306.sock [aa]>SET @@GLOBAL.GTID_PURGED='3db33b36-0e51-409f-a61d-c99756e90155:1-14,
'> ecf5373e-cad7-11e7-b854-000c293dbc8e:1'
-> ;
Query OK, 0 rows affected (0.00 sec)
3.安装官方文档正常初始化集群
步骤略
4.验证
"root@localhost:mysql3306.sock [aa]>start group_replication;
Query OK, 0 rows affected (3.16 sec)
"root@localhost:mysql3306.sock [aa]>select * from aa;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | a |
| 3 | a |
| 4 | a |
+----+------+
总结
1.如果需要添加一个节点
添加节点 需要自己手动在MGR集群中获得一致性备份,MGR集群不存在SST和IST概念,而是完全通过GTID和binlog来实现“追数据”的一个操作
2.节点宕机
如果MGR集群中某个节点宕机,如果宕机节点会询问存活集群,是否能补全binlog 如果能补齐,那么就会正常传输,进行追数据 。如果宕机节点需要的日志不存在了,则该节点无法正常加入集群环境中。
对于MGR一个建议
在宕机节点加入MGR集群中,如果发现需要的binlog日志不存在,则无法启动集群start group_replication