MySQL组复制（MGR）介绍

半亩方塘立身
776 阅读8分钟

组复制介绍

通过MySQL复制原理及应用我们了解到MySQL异步复制及半同步复制无法解决数据一致性问题，集群高可用、动态扩展等问题。MySQL5.7版本出现的MySQL Group Replication（简称MGR）较好解决了这些问题。

MGR一个全新的高可用与高扩展的解决方案，它提供了高可用、高扩展、高可靠的MySQL集群服务。下面是MySQL组复制插件架构图： image.png

以下是对该图中各组件的大致介绍：

  • 从上图的最顶端开始，有一系列的API控制组复制插件如何和MySQL Server进行交互(图中灰色方框)。
  • APIs:plugin从server获取正在启动、正在恢复、准备接受连接、即将提交事务等事件的通知
    plugin指示server提交/放弃运行的事务，将事务放到relay log队列中等等
  • 从API往下是一些响应组件，当通知信息路由到它们身上时就响应。
    • capture组件负责跟踪正在执行的事务的上下文信息。
    • applier组件负责在本节点上执行远程传输来的事务。
    • recovery组件负责管理分布式恢复过程，还负责在节点加入组时选择donor，编排追赶过程以及对选择donor失败时的反应。
  • Replication Protocol Logics:replication协议模块包含了特定的复制协议逻辑。它负责探测冲突，在组中接收和传播事务。
  • 最后两层是组内通信系统(GCS)的API(第一个绿色方框)，以及一个基于Paxos组通信引擎的实现(implementation)(第二个绿色方框)。
    • GCS API是组内通信API，它是一个上层API，它抽象了构建一个复制状态机所需的属性，它从插件的更上层解耦了消息传递层。
    • 组通信引擎负责处理组内成员的通信。

组复制优势

  • 在master-slave之间实现了强一致性；
    对于只读事务，组间实例无需进行通讯，就可以处理事务；对于读写(RW)事务，组内所有节点必须经过通讯，共同决定事务提交与否。
  • 事务冲突处理
    在高并发的多写模式下，节点间事务的提交可能会产生冲突，比如，两个不同的事务在两个节点上操作了同一行数据，这个时候就会产生冲突。首先，Group Replication（GR）能够识别到这个冲突，然后对此的处理是，依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，而后面的提交，会失败
  • 故障检测
    MGR自带故障检测机制，可以识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由其他节点决定是否将这个失效的节点从group里面剔除。
  • 动态成员管理 MGR需要维护组内节点的状态(ONLINE,RECOVERING,OFFLINE)，对于失效的节点，由其他节点决定是否剔除。对于新加入的节点，需要维护它的视图与其他节点的视图保持一致。
  • 高可用及容错性 MGR基于分布式一致性算法实现，一个组允许部分节点挂掉，只要保证大多数节点仍然存活并且之间的通讯是没有问题的，那么这个组对外仍然能够提供服务！假设一个MGR由2n+1个节点，那么允许n个节点失效，这个MGR仍然能够对外提供服务。比如有3个节点组成的一个GR，可允许1个节点失效，这个GR仍然能够提供服务。
  • 部署方便简单。

最后结论
对比之前的5.6的双主模式，5.7的组复制模式不管从部署还是管理都要方便很多。

组复制的限制

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

组复制模式

MGR提供了single-primary和multi-primary两种模式。

  • single-primary mode(单写模式) 组内只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持最终一致；
  • multi-primary mode(多写模式)，即写会下发到组内所有节点，组内所有节点同时可读，也是能够保证组内数据最终一致性。尤其要注意：一个MGR的所有节点必须配置使用同一种模式，不可混用！

组复制虽然也是传送Binlog Event，但并不像异步复制那样是简单的点到点传输。MGR在传输数据时，使用了Paxos协议，具体为Paxos的xcom组件。它的核心工作就是就是对所有数据包进行汇聚和排序，并且至少保证半数以上节点收到才会认为消息发送成功。在一致性协议层(consensus)实现了原子消息和全局有序消息，保证了数据传输的原子性（要么成功，要么失败）和一致性。

单写模式

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

多写模式

group内的所有机器都是primary节点，同时可以进行读写操作，并且数据是最终一致的。
该模式不好的地方在于: 非rpm包安装，目前使用rpm方式没有配置成功；启动还是处于手动方式，可以编写sys V方式启动脚本；性能上面没有做压测。

mysql组复制流程

image.png

  • MGR由若干个成员共同组成一个复制组，一个事务的提交，必须经过组内大多数成员（N / 2 + 1）确认收到消息后，才能进行决议并提交。
  • 由3个成员组成一个复制组，Consensus层为一致性协议层。在事务提交过程中，发生组间通讯，由2个节点确认收到消息后，并进行决议(certify)通过这个事务，才能够最终得以提交并响应。
  • 单主和多主的复制过程是一样的， 但在单主模式下，冲突检测是关闭的，备节点所有事务均可提交，而多主是必须要开启的。

从组复制原理上看，当主节点事务提交时，从节点上可能还未重放该事务对应的Binlog，因此MGR仍属于异步复制。但是在数据层MGR基于Paxos实现了数据的强一致，或者说多数派的强一致，这是毋庸置疑的。
一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。

  • 主库需要等待从库的确认，确保从库已经收到写入操作，那么复制是同步的，即强一致性。
  • 强一致性可以保证从库有与主库一致的数据。如果主库突然宕机，我们仍可以保证数据完整。但如果从库宕机或网络阻塞，主库就无法完成写入操作。
  • 强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。

MGR以组视图（Group View，简称视图）为基础来进行成员管理。视图指Group在一段时间内的成员状态，如果在这段时间内没有成员变化，也就是说没有成员加入或退出，则这段连续的时间为一个视图，如果发生了成员加入或退出变化，则视图也就发生了变化，MGR使用视图ID（View ID）来跟踪视图的变化并区分视图的先后时间。

参考
高性能MySQL
dev.mysql.com/doc/refman/…
blog.csdn.net/TIME_1981/a…

avatar
文章
阅读
粉丝