加入收藏 | 设为首页 | 会员中心 | 我要投稿 河北网 (https://www.hebeiwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

这个MySQL8.0.16新特征,你知道吗

发布时间:2019-05-21 15:11:17 所属栏目:编程 来源:智能运维小讲堂
导读:MGR优雅进级到MySQL8.0.16 传统的进级本领之一,5.7 MGR集群与8.0 MGR集群举办数据传输,措施切换新集群后测试是否正常,假如不正常,要么将新集群的新增数据同步回旧集群,要么就舍弃掉这部门数据,一样平常看来这种回滚都是繁琐的,繁琐的操纵一样平常城市响应的
副问题[/!--empirenews.page--]

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的组
这个MySQL8.0.16新特征你知道吗

两个焦点UDF (User Defined Function)

1. group_replication_get_communication_protocol

用于获取该MGR成员中最早的MySQL版本的通讯协议

  1. SELECT group_replication_get_communication_protocol(); 

2. group_replication_set_communication_protocol

必要变动MGR的通讯协议版本以便早期版本的成员可以插手,必要具有GROUP_REPLICATION_ADMIN 权限哦

  1. SELECT group_replication_set_communication_protocol("5.7.22"); 

假如后续将MGR的成员都进级成统一版本(原集群中最新的版本),通讯协议是不会自动进级兼容的,必要继承执行group_replication_set_communication_protocol函数来指定:

  1. SELECT group_replication_set_communication_pruseotocol("8.0.16"); 

DEMO

情形:

  1. 集群的节点: 
  2. 192.168.4.35:3309 - Primary Node - MySQL 5.7.25  
  3. 192.168.4.34:3309 - Seconds Node - MySQL 5.7.25 
  4. 192.168.4.36:3309 - Seconds Node - MySQL 5.7.25 
  5. 但愿插手集群的节点: 
  6. 192.168.4.35:3816 - MySQL 8.0.16 

开始测试

Primary Node (192.168.4.35 3309):

  1. show master status; 
  2. +-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 
  3. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | 
  4. +-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 
  5. | 0040353309-mysql-bin.000037 | 4090993 | | | 2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398 | 
  6. +-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 

新节点(192.168.4.35 3816)MySQL 8.0.16

  1. change master + install plugin 请自行完成 ​ 
  2. -- 假如通过还原已同步了GTID,忽略此步调,这里为了简朴测试,顾新节点没有同步原集群数据。 ​ 
  3. reset master; ​ 
  4. set global gtid_purge = '2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398'   
  5. -- 配置MGR相干参数 
  6. set global binlog_checksum = NONE; ​ 
  7. set global group_replication_group_name = '2c7b4762-5963-5789-acdd-047677b98a9d'; ​ 
  8. set global group_replication_local_address = '192.168.4.35:23816'; ​ 
  9. set global group_replication_group_seeds = "192.168.4.35:23309"; ​ 
  10. set global group_replication_bootstrap_group = off; ​ 
  11. set global group_replication_single_primary_mode = 0; ​ 
  12. set global group_replication_enforce_update_everywhere_checks = 0; ​ 
  13. set global group_replication_unreachable_majority_timeout = 120; ​ 
  14. set global group_replication_enforce_update_everywhere_checks = 1; 
  15. -- 启动集群 ​ 
  16. start group_replication ​ 
  17. -- 实行执行UDF:group_replication_get_communication_protocol: ​ 
  18. SELECT group_replication_get_communication_protocol(); 
  19. +------------------------------------------------+ 
  20. | group_replication_get_communication_protocol() | 
  21. +------------------------------------------------+ 
  22. | 5.7.14 | 
  23. +------------------------------------------------+ ​ 
  24. -- MySQL 8.0.16 插手由所有节点均为5.7.25版本,自动将通信协议降成了5.7.14,以便彼此通信兼容。 ​ 
  25. -- 同时也声名 MySQL的通讯协议版本也许和MySQL实例版本有也许不是同等的哦(这点还必要论证下,不敢打包票) ​ 
  26. -- 留意:假如呈现以下错误,缘故起因是执行UDF,必必要在集群成员均为Online对的状态下才可执行 
  27. -- ERROR 1123 (HY000): Can't initialize function 'group_replication_get_communication_protocol'; A member is joining the group, wait for it to be ONLINE.' 
  28. -- 查察集群节点状态: 
  29. [performance_schema]> select * from replication_group_members; 
  30. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 
  31. | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | 
  32. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 
  33. | group_replication_applier | 6990a8f4-777c-11e9-a906-20040fecc760 | node004035 | 3816 | ONLINE | SECONDARY | 8.0.16 | 
  34. | group_replication_applier | cc11c7de-446a-11e9-ae80-20040fecc760 | node004035 | 3309 | ONLINE | SECONDARY | 5.7.25 | 
  35. | group_replication_applier | cc830e26-446a-11e9-be34-20040fed73f8 | node004036 | 3309 | ONLINE | SECONDARY | 5.7.25 | 
  36. | group_replication_applier | cc88974a-446a-11e9-9e99-20040fed8fd8 | node004034 | 3309 | ONLINE | PRIMARY | 5.7.25 | 
  37. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 

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

总的来说,这个特征对付已5.7 MGR为主的公司,但又想体验8.0的一些特征是个很是好的利器。架构支持了差异的MySQL版本,玩法就可以多种多样了。

(编辑:河北网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读