1. MGR简介
基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证,MySQL官方在5.7.17版本正式推出组复制(MySQL Group Replication,简称MGR)。
由若干个节点共同组成一个复制组,一个事务的提交,必须经过组内大多数节点(N / 2 + 1)决议并通过,才能得以提交。如上图所示,由3个节点组成一个复制组,Consensus层为一致性协议层,在事务提交过程中,发生组间通讯,由2个节点决议(certify)通过这个事务,事务才能够最终得以提交并响应。
引入组复制,主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体),实现了分布式下数据的最终一致性,提供了真正的数据高可用方案
一个复制组由若干个节点(数据库实例)组成,组内各个节点维护各自的数据副本(Share Nothing),通过一致性协议实现原子消息和全局有序消息,来实现组内实例数据的一致。
2. MGR架构
MGR是一个MySQL Plugin(插件),简单来说,Plugin是MySQL官方提供的一套扩展机制,在MySQL实现事务处理、Binlog传输和持久化等操作时,在代码逻辑中预埋了一些(Hook)钩子,Plugin可以在钩子上注册处理函数,增加Plugin专有的功能实现。
Plugin提供了包括事务处理(Trans_observer)、服务器状态变化(Server_state_observer)、Binlog存储(Binlog_storage_observer)、Binlog发送(Binlog_transmit_observer)和Binlog回放(Binlog_relay_IO_observer)等不同功能模块的钩子集合。
举个栗子,比如事务处理钩子集包括了before_dml,before_commit,before_rollback,after_commit,after_rollback等五个钩子,分别用于在事务执行DML操作前,在事务提交前,在事务回滚前,在事务提交后,在事务回滚后进行特定的操作。
MGR作为一个官方插件,同样实现了这些钩子,其中事务处理集合的before_dml和before_commit是MGR中2个与事务处理相关的最主要钩子,注册函数分别为group_replication_trans_before_dml和group_replication_trans_before_commit,前者用于在执行DML前进行事务操作的合法性检查,包括所操作的表是否显式定义了主键,是否使用了InnoDB存储引擎等;后者是本文要重点介绍的MGR事务处理入口,它将MySQL中已经进入提交阶段的事务拦截下来,进入MGR处理流程,由MGR决定该事务应该提交还是回滚后,在返回MySQL通用代码进行后续处理。下图为作为Plugin的MGR整体框图。
3. MGR的解决方案现在具备的特性
数据一致性保障:确保集群中大部分节点收到日志
多节点写入支持:多写模式下支持集群中的所有节点都可以写入
Fault Tolerance: 确保系统发生故障(包括脑裂)依然可用,双写对系统无影响
4. MGR使用限制
- 仅支持innodb存储引擎
MGR集群中,只支持innodb存储引擎,能够创建非innodb引擎的表,但是无法写入数据,向非innodb表写数据直接报错。 - 表必须有主键,或者非Null的唯一键
MGR集群中,只支持innodb引擎的表,并且该表必须有显式的主键,或者非Null的唯一键,否则即使能够创建表,也无法向表中写入数据。 - 网络限制
MGR 组通信引擎目前仅支持IPv4网络,并且对节点间的网络性能要求较高,低延迟、高带宽的网络是部署MGR集群的基础。 - MGR忽略表锁和命名锁,在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。
- MGR多主模式中,默认不支持 SERIALIZABLE 隔离级别。
- 多主模式下,对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到,最终可能导致数据不一致。
- 多主模式下,不支持级联约束的外键,可能造成有冲突的操作无法检测。
- 不支持超大事务。
- 多主模式下可能导致死锁,比如select ...for update在不同节点执行,由于多节点锁无法共享,很容易导致死锁。
- 不支持复制过滤,如果有节点设置了复制过滤,将影响节点间决议的达成。
- MGR最多支持9个节点,大于9个节点,将拒绝新节点的加入。
本文参考:
https://zhuanlan.zhihu.com/p/40882015
https://www.cnblogs.com/luoahong/articles/8043035.html