MGR复制原理

 MGR复制原理
1.1 MGR插件体系结构
MGR是一个MySQL插件，它以现有的MySQL复制架构为基础，利用二进制日志、基于行的日志记录和全局事务标识符（GTID）等功能。



Capture/Apply/Lifecycle APIs：MGR插件包含一组捕获、应用和生命周期API，用于控制插件与MySQL服务器的交互方式。这些接口将MySQL服务器核心与MGR插件隔离。服务器向插件通知启动、恢复、准备接收连接、即将提交事务等消息。插件指示服务器执行诸如提交事务、中止正在进行的事务、事务在中继日志中排队等动作。

Capture/Apply/Recovery组件：

捕获组件Capture负责跟踪与正在执行的事务相关的上下文；
应用组件Apply负责在数据库上执行远程事务；
恢复组件Recovery管理分布式恢复，负责选择捐赠者，对故障做出反应，执行追赶程序，使加入该组的服务器获得更新。
Replication Protocol Logics：复制协议模块包含复制协议的特定逻辑。它处理冲突检测，接收事务并将其传播到组。

组复制插件体系结构的最后两层是组通信系统（GCS）API，以及基于Paxos的组通信引擎（XCom）的实现。GCS API将消息传递层的实现与插件上层分离，组通信引擎处理与复制组成员的通信。

1.2 MGR复制原理
组复制MGR技术是一种高可用系统的技术，其中复制组是由能够相互通信的多个服务器节点组成，在通信层则提供了原子消息和完全信息交互等保障机制，实现基于复制协议的多主更新。复制组由多个服务器组成，每个server成员可以独立的执行事务，但所有的读写RW事务只有在冲突检测成功后才会提交，只读RO事务则不需要冲突检测。因此，当一个读写事务准备提交的时候，会自动在组内进行原子性的广播，告知其它节点变更了什么内容、执行了什么事务。这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个组内保持了完全一致的状态。

MySQL组复制协议工作流程如下：


对于在不同的节点上执行的事务之间有可能存在资源争用，特别是在两个不同的并发事务上。假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。面对这种情况，组复制会判定先提交的事务为有效事务，会在整个组内重演，后提交的事务会直接中断，或者回滚，最后丢弃掉。因此，组复制MGR是一个无共享的复制方案，每一个节点都保存了完整的数据副本。

2 MGR复制模式
MGR有两种复制模式：单主模式和多主模式。在单主模式下，组复制具有自动选主功能，每次只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持最终一致。多主模式下，所有的节点都可以同时接受读写，也能够保证组内数据最终一致性。

1）单写模式

复制组内只有一台节点可写可读，其他节点只可以读。单写模式MGR的部署流程如下：

首先运行主节点（即那个可写可读的节点，read_only = 0）
运行其他的节点，并把这些节点一一加进group。其他的节点就会自动同步主节点上面的变化，然后将自己设置为只读模式（read_only = 1）。
当主节点意外宕机或者下线，在满足大多数节点存活的情况下，group内部发起选举，选出下一个可用的读节点，提升为主节点。
主选举根据group内剩下存活节点的UUID按字典序升序来选择，即剩余存活的节点按UUID字典序排列，然后选择排在最前的节点作为新的主节点。
2）多写模式

组内的所有机器都是主节点，同时可以进行读写操作，并且数据是最终一致的。

首先关闭单主模式开关loose-group_replication_single_primary_mode=OFF
运行第一个节点，设置loose-group_replication_bootstrap_group=ON
运行其它节点，并START GROUP_REPLICATION加入到group组中
当组内的某个节点发生故障时，会自动从将该节点从组内踢出，与其他节点隔离。剩余的节点之间保持主从复制的正常同步关系。当该节点的故障恢复后，只需手动激活组复制即可(即执行"START GROUP_REPLICATION;");
3 MGR复制特点
MGR复制有以下特点：


4 MGR复制的限制
存储引擎必须为Innodb，即仅支持InnoDB表
每个表必须提供主键，用于做write set的冲突检测
只支持ipv4，网络需求较高;
必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set;
COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景;
目前一个MGR集群组最多支持9个节点;
不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚;
二进制日志binlog不支持Replication event checksums;
多主模式(也就是多写模式) 不支持SERIALIZABLE事务隔离级别;
多主模式不能完全支持级联外键约束;
多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败);

原文链接：https://blog.csdn.net/solihawk/article/details/118183944