标签：8.0 Protocol 16 Communication 通信协议 replication MySQL group MGR
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)
从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状态。当新成员加入复制组时，它会检查通告的通信协议版本。 该小组的现有成员。 如果加入成员支持该版本，则它加入该组并使用该组已宣布的通信协议，即使该成员支持其他通信功能。 如果加入成员不支持通信协议版本，则将其从组中驱逐出去。
如果两个成员尝试加入相同的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
用于获取该MGR成员中最早的MySQL版本的通信协议SELECT group_replication_get_communication_protocol();
2. group_replication_set_communication_protocol
需要更改MGR的通信协议版本以便早期版本的成员可以加入，需要具有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
标签：8.0,Protocol,16,Communication,通信协议,replication,MySQL,group,MGR 来源： https://www.cnblogs.com/SQLServer2012/p/10884909.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。