关于mysql:1-MGR简介-深入浅出MGR

  • GreatSQL社区原创内容未经受权不得随便应用,转载请分割小编并注明起源。

1. 为什么是MGR

MGR是MySQL Group Replication的缩写,即MySQL组复制。

在以往,咱们个别是利用MySQL的主从复制或半同步复制来提供高可用解决方案,但这存在以下几个比较严重的问题:

  1. 主从复制间容易产生复制提早,尤其是在5.6以前的版本,以及当数据库实例中存在没有显式主键表时,很容易产生。
  2. 主从复制节点间的数据一致性无奈自行实现最终一致性。
  3. 当主节点产生故障时,如果有多个从节点,无奈主动从中抉择适合的节点作为新的主节点。
  4. 如果采纳(加强)半同步复制,那么当有个从节点因为负载较高、网络提早或其余意外因素使得事务无奈及时确认时,也会反过来影响主节点的事务提交。

因为上述几个显著的毛病,因而MySQL推出了全新的高可用解决方案 — 组复制,这是本系列文章要着重介绍的新个性。

MGR是MySQL 5.7.17开始引入的,但随着5.7版本逐步退出历史舞台(MySQL 5.7已于2020年10月起不再做大的性能更新,只有修修补补以及针对安全更新),更多MGR相干个性都只在MySQL 8.0上才有。

因而,如果线上还有基于MySQL 5.7版本的MGR环境的话,倡议尽快降级、迁徙到MySQL 8.0版本。进一步揭示,举荐MySQL 8.0.22及之后的版本,整体会更稳固牢靠,也有些很不错的新性能(不只是MGR方面的)。

2. MGR技术概要

MGR具备以下几个特点:

  1. 基于shared-nothing模式,所有节点都有一份残缺数据,产生故障时能够间接切换。
  2. MGR提供了数据一致性保障,默认是最终一致性,可依据业务特色须要自行调整一致性级别。
  3. 反对在线增加、删除节点,节点治理更不便。
  4. 反对故障自动检测及主动切换,产生故障时能主动切换到新的主节点,再配合MySQL Router中间件,应用层无需干涉或调整。
  5. 反对单节点、多节点写入两种模式,可依据架构或业务须要抉择哪种计划,不过强烈建议选用单主模式

MGR能够抉择单主(Single-Primary)模式

如上图所示,一开始S1节点是Primary角色,提供读写服务。当它产生故障时,剩下的S2-S5节点会再投票选举出S2作为新的Primary角色提供读写服务,而S1节点再达到肯定超时阈值后,就会被踢出。

亦可抉择多主(Multi-Primary)模式(再次强烈建议选用单主模式

如上图所示,一开始S1-S5所有节点都是Primary角色,都能够提供读写服务,任何一个节点产生故障时,只须要把指向这个节点的流量切换下就行。

上述两种架构模式下,利用端通过MySQL Router连贯后端在MGR服务,当后端节点产生切换时,Router会主动感知,对利用端来说简直是通明的,影响很小,架构上也更灵便。

3. MGR技术架构

首先来个MGR的技术架构图:

MGR是以Plugin形式嵌入MySQL,部署更灵便不便。

事务从Server层通过钩子(hook)进入MGR API接口层,再散发到各组件层,在组件层实现事务Capture/Apply/Recover,通过复制协定层(Replication Protocol Logics)传输事务,最初经由GCS协调事务在各节点的最终一致性。

MGR节点间由组通信零碎(GCS)提供反对,它提供了故障检测机制、组成员角色治理,以及平安且有序的消息传递,这些机制可确保在各节点间统一地复制数据。这项技术的外围是Paxos算法的实现,在MySQL里称之为XCom,由它充当MGR的通信引擎。

对于要提交的事务,组中的多数派节点必须就全局事务序列中给定的事务程序达成统一。各节点做出决定提交或停止事务的抉择,但所有节点都要做出雷同的决定。如果产生网络分区,导致节点间无奈达成统一决定,则在网络复原前,MGR无奈工作。

MGR反对单主和多主两种模式,在单主模式下,各节点会主动选定主节点,只有该主节点能同时读写,而其余(从)节点只能只读。在多主模式下,所有节点都能够进行读写。

绝对于MariaDB Galera Cluster(以及基于此技术的Percona XtraDB Cluster,上面为了书写不便,都统称为PXC),集体认为MGR具备以下几个劣势:

  1. PXC的音讯播送机制是在节点间循环的,须要所有节点都确认音讯,因而只有有一个节点故障,则会导致整个PXC都产生故障。而MGR则是多数派投票模式,个别少数派节点故障时,个别不影响整体的可用性。这也是PXC存在的最大问题。
  2. PXC的节点间数据传输除了binlog,还有个gcache,这相当于是给MySQL又减少两个黑盒子。而MGR则都是基于原生binlog的,没有新增黑盒子,运行起来更牢靠,须要排障时也更不便。
  3. 产生网络分区时,整个PXC集群都不可用。而MGR则至多还能提供只读服务。
  4. PXC的流控机制影响更大,一旦触发流控,所有节点都受到影响。而MGR触发流控后,只会影响本地节点,不影响近程节点。当然了,MySQL的流控做的也比拟毛糙,在GreatSQL中进一步欠缺和优化。
  5. 执行DDL期间,整个PXC集群都不可同时执行DML,也就是说不反对Online DDL。而MGR是反对的,这也是很大的劣势。

绝对于传统主从复制(Replication),我认为MGR的劣势有以下几点:

  1. 主从复制非常容易产生复制提早,尤其是当表中没有显式主键时。而在MGR里,要求表肯定要有主键(或是可用作汇集索引的非空惟一索引),防止了这个问题。
  2. 半同步复制中,一旦slave因为锁或其余起因响应慢的话,也会导致master事务被阻塞。MGR是采纳多数派确认机制,个别节点响应慢对Primary节点的影响没那么大(不要选用AFTER模式)。
  3. 主从复制没有相似MGR那样提供事务数据的一致性保障。MGR自带了事务数据一致性保障机制。

以上是我依据MySQL、MariaDB、Percona的材料整顿失去的观点,不肯定精确和全面,有不欠缺的中央还请留言斧正。

4. 小结

本节次要介绍了什么是MGR,MGR的技术架构概要,以及MGR绝对PXC的几个技术劣势。

MGR是MySQL四部策略走的要害一环,依附MGR和MySQL Shell、MySQL Router已实现了读节点扩大,以及写节点扩大(MGR多主模式),下一步预计实现sharding,让咱们刮目相待。

置信MGR也是MySQL将来几年的重头戏,倡议跟紧方向,不要错过这班列车。

参考资料、文档

  • MySQL 8.0 Reference Manual
  • 数据库内核开发 – 温正湖
  • Group Replication原理 – 宋利兵

免责申明

因集体程度无限,专栏中不免存在错漏之处,请勿间接复制文档中的命令、办法间接利用于线上生产环境。请读者们务必先充沛了解并在测试环境验证通过前方可正式施行,防止造成生产环境的毁坏或侵害。

Enjoy GreatSQL 🙂

文章举荐:

GreatSQL季报(2021.12.26)
https://mp.weixin.qq.com/s/FZ…

技术分享|sysbench 压测工具用法浅析
https://mp.weixin.qq.com/s/m1…

故障剖析 | linux 磁盘io利用率高,剖析的正确姿态
https://mp.weixin.qq.com/s/7c…

技术分享|闪回在MySQL中的实现和改良
https://mp.weixin.qq.com/s/6j…

万答#20,索引下推如何进行数据过滤
https://mp.weixin.qq.com/s/pt…

对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支,专一于晋升MGR可靠性及性能,反对InnoDB并行查问个性,是实用于金融级利用的MySQL分支版本。

Gitee:
https://gitee.com/GreatSQL/Gr…

GitHub:
https://github.com/GreatSQL/G…

Bilibili:
https://space.bilibili.com/13…

微信&QQ群:
可搜寻增加GreatSQL社区助手微信好友,发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群:533341697
微信小助手:wanlidbc

本文由博客一文多发平台 OpenWrite 公布!

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据