mgr未同步 mysql_MySQL MGR 真正的多主/多写实战

MGR 背景

在 MGR 组复制出现之前，MySQL 对于高可用环境都是需要外部软件支持，如 MHA、Keepalived、Haproxy 等中间件支持，而且并没有做到真正的多写。

因此，最终的挑战是将数据库和数据复制的逻辑与以一致和简单的方式协调多个服务器的逻辑融合在一起。换句话说，让多个服务器就系统的状态和系统经历的每个更改的数据达成一致。这可以概括为让服务器在每个数据库状态转换上达成一致，以便它们都作为单个数据库进行，或者最终收敛到相同的状态。这意味着它们需要作为(分布式)状态机运行。

MySQL

组复制提供分布式状态机复制，服务器之间具有很强的协调性。当服务器是同一组的一部分时，它们会自动协调自身。该组可以在具有自动主选择的单主模式中运行，一次只有一台服务器接受更新。或者，对于更高级的用户，可以以多主模式部署该组，其中所有服务器都可以接受更新，即使它们同时发出。这种能力以牺牲应用程序必须绕过此类部署施加的限制为代价。

有一个内置的组成员身份服务，使组视图保持一致，并在任何给定时间点可供所有服务器使用。服务器可以离开并加入组，视图会相应地更新。有时服务器可能会意外离开组，在这种情况下，故障检测机制会检测到此情况，并通知组视图已更改。这是自动的。

要提交事务，大多数组必须就全局事务序列中给定事务的顺序达成一致。决定提交或中止事务由每个服务器单独完成，但所有服务器都做出相同的决策。如果存在网络分区，导致成员无法达成协议的拆分，则在解决此问题之前，系统不会取得进展。因此，还有一个内置的，自动的，大脑的分离保护机制。

所有这些都由提供的组通信系统 (GCS)

协议提供支持。它们提供故障检测机制、组成员身份服务以及安全且完全有序的消息传递。所有这些属性都是创建系统的关键，该系统可确保数据在服务器组中一致复制。这项技术的核心是 Paxos 算法的实现。它充当组通信引擎。

总的来说数据库层面已经不多主写入的限制了，交由中间件来做就比较容易了，如 ProxySQL、MySQL-router、Xeon 等。

MGR 原理

组复制是一种可用于实现容错系统的技术。复制组是一组服务器，每个服务器都有自己的整个数据副本(无共享复制方案)，并通过消息传递相互交互。通信层提供一组保证，如原子消息和总订单消息传递。这些都是非常强大的属性，可以转换为非常有用的抽象，可以采用构建更高级的数据库复制解决方案。

MySQL

组复制基于此类属性和抽象构建，并实现无处不在的复制协议中的多源更新。复制组由多台服务器组成，该组中的每个服务器可随时独立执行事务。但是，所有读写事务仅在组批准后提交。换句话说，对于任何读写事务，组需要决定是否提交，因此提交操作不是来自原始服务器的单边决策。只读事务不需要在组内进行协调并立即提交。

当读写事务准备在原始服务器上提交时，服务器以原子方式广播写入值(已更改的行)和相应的写入集(已更新的行的唯一标识符)。由于事务是通过原子广播发送的，因此组中的所有服务器都接收事务，或者没有服务器接收事务。如果他们收到它，那么他们都收到它的顺序与之前发送的其他事务相同。因此，所有服务器以相同的顺序接收同一组事务，并设置为事务建立的全局总顺序。

但是，在不同的服务器上同时执行的事务之间可能会发生冲突。通过检查和比较两个不同和并发事务的写入集，在称为认证的进程中检测和比较此类冲突。在认证期间，冲突检测在行级别执行：如果两个并发事务，在不同的服务器上执行，更新同一行，则存在冲突。冲突解决过程指出，排序的事务首先在所有服务器上提交，事务下令第二次中止，因此在原始服务器上回滚，并由组中的其他服务器删除。

例如：

如果 t1 和 t2 在不同的站点上并发执行，则更改同一行和 t2 在 t1 之前排序，则 t2 将赢得冲突，并回滚 t1。这实际上是一个分布式的第一个提交获胜规则。请注意，如果两个事务经常发生冲突，则在同一服务器上启动它们是一种好的做法，即它们有机会在本地锁管理器上同步，而不是由于认证而回滚。

对于应用和外部化认证交易，组复制允许服务器偏离交易的商定顺序，如果这不破坏一致性和有效性。组复制是一个最终的一致性系统，这意味着一旦传入的流量减慢或停止，所有组成员都具有相同的数据内容。当流量流动时，事务可以以略有不同的顺序外化，也可以在其他成员之前外部化。例如，在多主模式中，本地事务可能在认证后立即外部化，尽管尚未应用全局订单中较早的远程事务。当认证过程确定事务之间没有冲突时，允许这样做。在主服务器上的单主模式中，并发、非冲突的本地事务以不同于组复制商定的全局顺序的顺序提交和外部化的可能性很小。在不接受客户端写入的二级，事务始终按约定的顺序提交和外部化。

下图描述了 MySQL 组复制协议。

插件结构

capture 组件负责跟踪与正在执行的事务相关的上下文信息。

applier 组件负责在数据库上执行(应用)远程事务，其实就是读取 relay log 中数据进行回放。

Recovery 组件管理数据库节点的分布式恢复相关的工作。

组复制插件体系结构的最后两层是组通信系统(GCS)API 和基于 Paxos 的组通信引擎(XCom)的实现。使用场景：

弹性复制：需要非常流畅的复制基础结构的环境，其中服务器的数量必须动态增长或收缩，并且副作用尽可能少。例如，云的数据库服务。

高可用分片：分片是实现写入扩展的一种流行方法。使用 MySQL 组复制实现高可用分片，其中每个分片映射到复制组。

异步源副本复制的替代：在某些情况下，使用单个源服务器使它成为单个争用点。在某些情况下，写入整个团队可能会更加可扩展。

自治系统：此外，您可以部署 MySQL 组复制，这完全是为了复制协议中内置的自动化。

使用限制

间隙锁：组复制的并发事务的认证过程没有考虑间隙锁，建议使用 RC 事务隔离级别。

Binary Log Checksums：在 MySQL 8.0.20 之前(包括)中，组复制不能使用校验和，并且不支持它们出现在二进制日志中，因此在配置将成为组成员的服务器实例时必须设置 binlog_checksum=NONE。

从 MySQL 8.0.21 中，组复制支持校验和，因此组成员可以使用默认 binlog_checksum=CRC32。不支持 SERIALIZABLE 隔离级别并发 DDL 与 DML 操作。使用多主模式时，不支持针对同一对象执行，但在不同的服务器上执行的并发数据定义语句和数据操作语句具有级联约束的外键。多主模式组(所有配置有 group_replication_single_primary_mode=OFF 的成员)不支持具有多级外键依赖项的表，可以成为单个复制组成员的 MySQL 服务器的最大数量为 9。

故障切换流程

单主模式

在单主模式下，组具有设置为读写模式的单个主服务器。组中的所有成员都设置为只读模式(super_read_only=ON)。主服务器通常是第一个引导组的服务器。加入组的所有其他服务器都会了解主服务器，并自动设置为只读模式。

在单主模式中，组复制强制只有一台服务器写入组，因此与多主模式相比，一致性检查可能不太严格，并且不需要格外小心地处理 DDL 语句。

选主顺序：

考虑的第一个因素是哪个成员或成员运行最低的 MySQL 服务器版本。

如果多个成员运行最低的 MySQL Server 版本，则考虑的第二个因素是每个成员的成员权重，如 group_replication_member_weight 上的 group_replication_member_weight 系统变量所指定。

如果多个成员运行的最低 MySQL Server 版本，并且其中多个成员的成员权重最高(或成员权重被忽略)，则考虑的第三个因素是每个成员生成的服务器 UUID 的词汇顺序，由 server_uuid 系统变量指定。

多主模式