共计 4138 个字符，预计需要花费 11 分钟才能阅读完成。
- GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
1. 传统主从复制技术架构
传统主从复制的形式是在 master 节点上执行数据更新事务，而后记录这些事务到 binlog 中，再将 binlog 发送到 slave 节点转储成 relay log，在 slave 节点上再有独自的线程读取这些 relay log 而后从新执行或利用这些事务，它是 shared-nothing 的，每个节点都有一份残缺的数据正本，其技术流程图如下所示：
- 传统主从复制技术架构图
MySQL 还提供了半同步复制，这是在传统主从复制的根底上减少了一个同步的步骤，master 节点上提交事务前，要先等到 slave 节点确认收到事务信息才能够（所以前文才说当 slave 节点响应慢时会影响 master 节点的事务提交），其技术流程图如下所示：
- 半同步复制技术架构图
2. MGR 组复制技术架构
MGR 也是 shared-nothing 的，每个节点都有一份残缺的数据正本，节点间通过 GCS（Group Communication System）进行交互。GCS 层提供了节点间的全局音讯及其有序性的保障。
MGR 能够做到在任何节点、任何工夫都能执行读写事务（不含只读事务），不过读写事务要被整个复制组确认后能力提交。如果是只读事务则没有这个限度，任何节点都能够发动及提交。
当读写事务筹备提交前，它会向复制组收回一个原子播送，内容包含：该事务批改的数据，及其所对应的 writeset。复制组中所有节点要么接管该事务，要么都不接管。如果组中所有节点都接管该事务音讯，那么它们都会依照与之前发送事务的雷同程序收到该播送音讯。因而，所有组成员都以雷同的程序接管事务的写集，并为事务建设全局程序。
在多个节点上并行执行的事务是可能产生抵触的，这时候就须要比照判断两个并行事务的 writeset 来确认，这个过程称为 事务认证 ，也叫做 冲突检测 。事务冲突检测是行级别的，也就是说两个并行的事务更新同一行时，则视为产生抵触。这时的做法是全局程序在后面的事务能够胜利，所有节点都提交该事务。而全局程序在前面的事务会失败回滚，各节点会删除该事务。这实际上是个分布式的谁先提交谁先博得事务的规定。 倡议：如果常常产生节点间的事务抵触，那最好将这些事务放在同一个节点上执行，这样它们在本地事务并发管制协调下可能都能够提交胜利，而不至于因为 MGR 的冲突检测而导致某个事务总是被回滚。
对于正在利用或外化的事务，MGR 容许它们不肯定依照原有程序执行，只有不毁坏事务的一致性和有效性即可。MGR 默认要求是最终一致性，也就是说当所有事务都利用结束后，所有节点的数据是统一的。当流量微小时，事务可能会被外化而导致程序轻微不统一。例如在多主模式下，一个本地事务在通过认证后会被立刻外化，只管此时可能还有个有这更早全局程序的近程事务还没被利用，只有 MGR 的认证线程认为这个事务不会产生抵触即可。在单主模式下，在 Primary 节点上的本地并发事务，在不产生抵触的状况下，其提交和外化的程序可能和该事物的全局事务程序有轻微不统一。在 Secondary 节点上，因为没有写事务，因而它们的事务程序和全局事务程序是统一的。
下图形容了 MGR 的组复制协定，能够看到和传统主从复制（及半同步复制）的一些差别。为了简略起见，图中少了共识算法和 Paxos 相干的信息：
- MGR 技术架构图
3. MGR 的单主和多主模式
MGR 反对单主或多主两种模式。
在启动时，通过设置选项 group_replication_single_primary_mode 来决定应用哪种模式，各节点中该值的设置要求统一。设置为 ON 时示意采纳 单主模式 ，当设置为 OFF 时示意采纳 多主模式。
在运行过程中，不能在线批改 group_replication_single_primary_mode 的值，然而从 MySQL 8.0.13 开始，能够通过调用 group_replication_switch_to_single_primary_mode() 和 group_replication_switch_to_multi_primary_mode() 这两个 udf 在线批改运行模式，或者通过 MySQL Shell 批改。
在 单主模式 下，有且只有一个（Primary）节点能够写入数据，其余（Secondary）节点都只能读数据。而在 多主模式 下，能够在任意节点上同时读写数据。
MGR 最多只能反对 9 个节点，无论单主还是多主模式。
4. 节点治理
MGR 由一组节点形成，每个节点都有惟一的名字，以 UUID 的格局体现。节点能够动静退出或来到（也可能是被动被驱赶）MGR。
MGR 的组成员服务用于保护定义各沉闷节点的信息，这些沉闷节点信息也称之为 组视图（view）。各节点的组视图是统一的，这示意在给定时刻组中有哪些沉闷成员。
MGR 各节点除了在事务提交时要保持一致外，也包含组视图发生变化时也要达成统一。当有新节点退出，或现有节点来到时，都会触发新的组视图变更。
当有节点被动来到集群时，它会触发集群主动重配置，剩下的节点会就新的组视图达成统一。但若节点是因为网络异样或宕机等起因意外来到集群时，则无奈触发主动重配置，这时候集群故障检测机制会在该节点来到一段时间后辨认到这个状态，并收回重配置组视图的提议。重配置组视图须要失去多数派成员的批准才行，当无奈造成统一时，就无奈实现主动重配置，须要人工染指解决。无奈造成一致意见可能的起因有，剩下的节点数没达到总结点数的一半以上，也就是无奈造成多数派。
在节点被确认故障之前，或在重新配置组以删除该故障节点前，容许该节点短暂离线，而后尝试重新加入集群。在这种状况下，该节点可能会失落它以前的状态（事务数据），如果此时其余节点向它发送了蕴含解体前的音讯，则这就可能会导致数据不统一等问题。
为了解决这个问题，从 MySQL 5.7.22 开始，MGR 会查看具备雷同地址 + 端口的节点再次以新身份退出集群的状况，确认以后是否还有其旧身份存在。这时候其新身份不能退出，直到旧身份能从集群中删掉。留神：，选项 group_replication_member_expel_timeout 的作用是设置一个期待期，使得节点在被正式驱赶前有更多工夫尝试从新加回集群，也就是说处于被狐疑状态的节点，在超时之前还可尝试重新加入集群，再次作为沉闷节点。当节点超过 group_replication_member_expel_timeout 阈值并被从集群中驱赶时，或节点执行 STOP GROUP_REPLICATION 退出集群，或因节点宕机等状况下，该节点必须以新身份重新加入集群。
5. 故障检测
MGR 自带故障检测机制，它能发现并报告哪个节点处于静默状态，达到肯定条件后会认为这个节点已死。它是个分布式的故障检测服务，提供了哪个节点处于（被狐疑）已死状态的信息。
当一个节点静默（不被动发信息，也不回复其余节点的信息）时，可能会触发被狐疑。当节点 A 在给定工夫内还没有收到节点 B 的音讯时，则产生音讯超时并引发狐疑。在这之后，集群内其余成员如果一致同意（多数派达成统一）对该节点的狐疑是确定的话，则会断定该节点产生了故障。
如果某个节点因为网络故障和其余节点断开连接了，那么它可能也会狐疑其余节点产生了故障。但因为它不能造成多数派决定，因而这个狐疑是有效的，此时该节点无奈执行任何读写事务，最多只能执行只读事务。
当网络不稳固时，随便两个节点间可能频繁断开和重连，实践上说可能会导致所有节点都会标记为驱赶，集群会退出并须要重建。为了防止这种状况，从 MySQL 8.0.20 开始，GCS 会跟踪标记为驱赶的节点，并决定某个可疑节点是否还留在多数派节点中，这使得集群中至多有一个节点而不会退出。当被驱赶节点正式被从集群中移出时，GCS 会删掉起被标记为驱赶的记录，使得它前面还能从新加回。
6. 容错机制
MGR 是基于分布式的 Paxos 算法实现，因而要求有多数派节点存活以保障投票。这就决定了在不影响零碎整体可用性前提下，可容忍产生故障的节点数量。假如总节点数是 n，可容忍产生故障的节点数是 f，则它们的关系是：n = 2*f + 1。简言之，容忍产生故障的节点数，不高于总节点数的一半。
下表展现了不同节点数的对应关系：
| 总节点数 | 多数派节点数 | 最大容忍故障节点数 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
| 8 | 5 | 3 |
| 9 | 5 | 4 |
参考资料、文档
- 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 公布！
