• 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 公布！