作者介绍：张充(Paddy) 微信号：paddyzc，参与数据库工作11年有余，现任马蜂窝DBA团队负责人。主要参与数据库运维、架构、智能自动化方面等工作。同时作为知数堂学员之一，希望将自己所学所得分享与他人，在数据库这条道路上继续前行。
一、前言
传统的升级手段之一，5.7 MGR集群与8.0 MGR集群进行数据传输，程序切换新集群后测试是否正常.
如果不正常，要么将新集群的新增数据同步回旧集群，要么就舍弃掉这部分数据，一般看来这种回滚都是繁琐的，繁琐的操作一般都会相应的增加风险。
8.0.16的发布也带来一个新的功能-MGR通信协议的支持，可以让我们更轻松地切换到8.0mysql升级，或者轻松地再切换回5.7。那么什么是MGR通信协议呢？
二、MGR通信协议(The CommunicationProtocol In Group Replication)
从MySQL 8.0.16中，MGR有一个通信协议的概念。可以直接管理MGR通信协议版本，并将其设置为适应你希望MGR成员支持的哪个MySQL服务器版本。
从而实现同一个MGR可用组中可以由不同MySQL服务器版本的成员组成。
是的你没有看错，也就是说：
成员1：8.0.16 成员2：8.0.16 成员3：5.7.22 他们可以组成一个MGR集群了。
无论从集群的迁移成本，应用程序切换过程的平滑度，回滚时数据一致性都可以更好的保障。
应用程序切换过程的平滑度：老司机会有感触，一般应用程序都是多个节点，每个节点访问新地址的生效存在时间差，会导致新旧节点会存在有数据同时写入情况，这个就会成为架构的设计的核心考虑之一。
同时确保向后兼容性。MySQL 5.7.14的版本允许压缩消息，而MySQL 8.0.16的版本也允许消息碎片化。
同一个组中的所有成员必须使用相同的通信协议版本，以便MGR成员虽然各自处于不同的MySQL版本，但他们之间只能发送所有MGR成员都能理解的消息。
如果组的通信协议版本小于或等于X，则版本X的MySQL服务器只能在复制组中加入并达到ONLINE状态。当新成员加入复制组时，它会检查通告的通信协议版本。
该小组的现有成员。如果加入成员支持该版本，则它加入该组并使用该组已宣布的通信协议，即使该成员支持其他通信功能。如果加入成员不支持通信协议版本mysql升级，则将其从组中驱逐出去。
如果两个成员尝试加入相同的MGR集群，则只有两个成员的通信协议版本已与该MGR已有成员的通信协议版本兼容时，它们才能加入。来自该组的具有不同通信协议版本的成员必须单独加入。
例如：
两个核心UDF (User Defined Function)
1.group_replication_get_communication_protocol
用于获取该MGR成员中最早的MySQL版本的通信协议
2. group_replication_set_communication_protocol
需要更改MGR的通信协议版本以便早期版本的成员可以加入，需要具有GROUP_REPLICATION_ADMIN权限哦
如果后续将MGR的成员都升级成同一版本（原集群中最新的版本），通信协议是不会自动升级兼容的，需要继续执行group_replication_set_communication_protocol函数来指定：
三、DEMO
环境：
开始测试：
Primary Node(192.168.4.35 3309)：
新节点（192.168.4.35 3816）MySQL 8.0.16
搭建完成，均手工测试，数据可正常同步及读取。测试数据就不在这里介绍，可自行玩耍。
四、小结
总的来说，这个特性对于已5.7 MGR为主的公司，但又想体验8.0的一些特性是个非常好的利器。
架构支持了不同的MySQL版本，玩法就可以多种多样了。
迁移时一定要注意数据一致性，第一优先级保证：无论迁移前、中、后的数据同步，或者迁移后的失败迁，都要保证两边数据一定要一致。当你面临修复数据，你就会知道它是个无底洞了。
参考文档：
关于「3306π」社区
围绕MySQL核心技术，将互联网行业中最重要的数据化解决方案带到传统行业中；囊括其他开源技术Redis、MongoDB、Hbase、Hadoop、ElasticSearch、Storm、Spark等；分享干货知识，即便是赞助商，也要求如此，拒绝放水。
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：jiumai99