MySQL8.0.16新特性：The Communication Protocol In Group Replication

时间 2019-11-17

标签 mysql8.0.16 mysql 特性 communication protocol group replication 栏目 MySQL 繁體版

原文原文链接

MGR优雅升级到MySQL8.0.16

　　传统的升级手段之一，5.7 MGR集群与8.0 MGR集群进行数据传输，程序切换新集群后测试是否正常.html

　　若是不正常，要么将新集群的新增数据同步回旧集群，要么就舍弃掉这部分数据，通常看来这种回滚都是繁琐的，繁琐的操做通常都会相应的增长风险。node

　　8.0.16的发布也带来一个新的功能-MGR通讯协议的支持，可让咱们更轻松地切换到8.0，或者轻松地再切换回5.7。那么什么是MGR通讯协议呢？ mysql

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集群了。

　　不管从集群的迁移成本，应用程序切换过程的平滑度，回滚时数据一致性均可以更好的保障。sql

　应用程序切换过程的平滑度：老司机会有感触，通常应用程序都是多个节点，每一个节点访问新地址的生效存在时间差，会致使新旧节点会存在有数据同时写入状况，这个就会成为架构的设计的核心考虑之一。

同时确保向后兼容性。MySQL 5.7.14的版本容许压缩消息，而MySQL 8.0.16的版本也容许消息碎片化。

同一个组中的全部成员必须使用相同的通讯协议版本，以便MGR成员虽然各自处于不一样的MySQL版本，但他们之间只能发送全部MGR成员都能理解的消息。

若是组的通讯协议版本小于或等于X，则版本X的MySQL服务器只能在复制组中加入并达到ONLINE状态。当新成员加入复制组时，它会检查通告的通讯协议版本。

该小组的现有成员。若是加入成员支持该版本，则它加入该组并使用该组已宣布的通讯协议，即便该成员支持其余通讯功能。若是加入成员不支持通讯协议版本，则将其从组中驱逐出去。

若是两个成员尝试加入相同的MGR集群，则只有两个成员的通讯协议版本已与该MGR已有成员的通讯协议版本兼容时，它们才能加入。来自该组的具备不一样通讯协议版本的成员必须单独加入。 bootstrap

例如：服务器

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         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

　　搭建完成，均手工测试，数据可正常同步及读取。测试数据就不在这里介绍，可自行玩耍。app

小结

　　总的来讲，这个特性对于已5.7 MGR为主的公司，但又想体验8.0的一些特性是个很是好的利器。ide

　　架构支持了不一样的MySQL版本，玩法就能够多种多样了。函数

　　迁移时必定要注意数据一致性，第一优先级保证：不管迁移前、中、后的数据同步，或者迁移后的失败回迁，都要保证两边数据必定要一致。当你面临修复数据，你就会知道它是个无底洞了。

参考文档：

https://dev.mysql.com/doc/refman/8.0/en/group-replication-communication-protocol.html