引言
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