MGR优雅升级到MySQL8.0.16
传统的升级手段之一,5.7 MGR集群与8.0 MGR集群进行数据传输,程序切换新集群后测试是否正常.
如果不正常,要么将新集群的新增数据同步回旧集群,要么就舍弃掉这部分数据,一般看来这种回滚都是繁琐的,繁琐的操作一般都会相应的增加风险。
8.0.16的发布也带来一个新的功能-MGR通信协议的支持,可以让我们更轻松地切换到8.0,或者轻松地再切换回5.7。那么什么是MGR通信协议呢?
MGR通信协议(The Communication Protocol In Group Replication)
成员1:8.0.16 成员2:8.0.16 成员3:5.7.22 他们可以组成一个MGR集群了。
无论从集群的迁移成本,应用程序切换过程的平滑度,回滚时数据一致性都可以更好的保障。
应用程序切换过程的平滑度:老司机会有感触,一般应用程序都是多个节点,每个节点访问新地址的生效存在时间差,会导致新旧节点会存在有数据同时写入情况,这个就会成为架构的设计的核心考虑之一。
如果两个成员尝试加入相同的MGR集群,则只有两个成员的通信协议版本已与该MGR已有成员的通信协议版本兼容时,它们才能加入。 来自该组的具有不同通信协议版本的成员必须单独加入。
例如:
1个MySQL Server 8.0.16实例可以成功加入使用通信协议版本为5.7.22的组。
1个MySQL Server 5.7.22实例无法加入使用通信协议版本为8.0.16的组。
2个MySQL Server 8.0.16实例无法同时加入使用通信协议版本为5.7.22的组。
2个MySQL Server 8.0.16实例可以同时加入使用通信协议版本8.0.16的组
两个核心UDF (User Defined Function)
1. group_replication_get_communication_protocol
SELECT group_replication_get_communication_protocol();
2. group_replication_set_communication_protocol
GROUP_REPLICATION_ADMIN
权限哦
SELECT group_replication_set_communication_protocol("5.7.22");
如果后续将MGR的成员都升级成同一版本(原集群中最新的版本),通信协议是不会自动升级兼容的,需要继续执行group_replication_set_communication_protocol函数来指定:
SELECT group_replication_set_communication_pruseotocol("8.0.16");
DEMO
环境:
集群的节点:
192.168.4.35:3309 - Primary Node - MySQL 5.7.25
192.168.4.34:3309 - Seconds Node - MySQL 5.7.25
192.168.4.36:3309 - Seconds Node - MySQL 5.7.25
希望加入集群的节点:
192.168.4.35:3816 - MySQL 8.0.16
开始测试
Primary Node (192.168.4.35 3309):
show master status;
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+
| 0040353309-mysql-bin.000037 | 4090993 | | | 2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398 |
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+
新节点(192.168.4.35 3816)MySQL 8.0.16
change master + install plugin 请自行完成
-- 如果通过还原已同步了GTID,忽略此步骤,这里为了简单测试,顾新节点没有同步原集群数据。
reset master;
set global gtid_purge = '2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398'
-- 设置MGR相关参数
set global binlog_checksum = NONE;
set global group_replication_group_name = '2c7b4762-5963-5789-acdd-047677b98a9d';
set global group_replication_local_address = '192.168.4.35:23816';
set global group_replication_group_seeds = "192.168.4.35:23309";
set global group_replication_bootstrap_group = off;
set global group_replication_single_primary_mode = 0;
set global group_replication_enforce_update_everywhere_checks = 0;
set global group_replication_unreachable_majority_timeout = 120;
set global group_replication_enforce_update_everywhere_checks = 1;
-- 启动集群
start group_replication
-- 尝试执行UDF:group_replication_get_communication_protocol:
SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 5.7.14 |
+------------------------------------------------+
-- MySQL 8.0.16 加入由全部节点均为5.7.25版本,自动将通讯协议降成了5.7.14,以便相互通讯兼容。
-- 同时也说明 MySQL的通信协议版本可能和MySQL实例版本有可能不是一致的哦(这点还需要论证下,不敢打包票)
-- 注意:如果出现以下错误,原因是执行UDF,必须要在集群成员均为Online对的状态下才可执行
-- ERROR 1123 (HY000): Can't initialize function 'group_replication_get_communication_protocol'; A member is joining the group, wait for it to be ONLINE.'
-- 查看集群节点状态:
[performance_schema]> select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 6990a8f4-777c-11e9-a906-20040fecc760 | node004035 | 3816 | ONLINE | SECONDARY | 8.0.16 |
| group_replication_applier | cc11c7de-446a-11e9-ae80-20040fecc760 | node004035 | 3309 | ONLINE | SECONDARY | 5.7.25 |
| group_replication_applier | cc830e26-446a-11e9-be34-20040fed73f8 | node004036 | 3309 | ONLINE | SECONDARY | 5.7.25 |
| group_replication_applier | cc88974a-446a-11e9-9e99-20040fed8fd8 | node004034 | 3309 | ONLINE | PRIMARY | 5.7.25 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
搭建完成,均手工测试,数据可正常同步及读取。测试数据就不在这里介绍,可自行玩耍。
小结
总的来说,这个特性对于已5.7 MGR为主的公司,但又想体验8.0的一些特性是个非常好的利器。
架构支持了不同的MySQL版本,玩法就可以多种多样了。
迁移时一定要注意数据一致性,第一优先级保证:无论迁移前、中、后的数据同步,或者迁移后的失败回迁,都要保证两边数据一定要一致。当你面临修复数据,你就会知道它是个无底洞了。
参考文档:
https://dev.mysql.com/doc/refman/8.0/en/group-replication-communication-protocol.html
来源:oschina
链接:https://my.oschina.net/u/4413313/blog/3294648