MySQL Group Replication 学习笔记

作者简介

刘伟  云和开创高级顾问

题记：group replication作为mysql官方，在5.7版本阶段开发的，innodb的分布式数据库架构，从发布开始就有很多关注，下文是我对目前为止的材料以及实验的一些总结。

主要资料来源是官方blog：http://mysqlhighavailability.com/

group replication架构

group replication（后文简称GR）实现的分布式数据库架构，底层的分布式基础是Paxos（出于行文限制，此处不单独交代Paxos）。通过Paxos来保证分布式数据库系统中，事务的提交顺序。

每次一个事务在一个节点提交的时候，就会发送所修改的数据到所有节点，检查期间是否有修改冲突（比如修改了别的节点已经修改并提交成功的事务的数据），如果发现冲突，本事务回滚。如果没有冲突，则可以直接提交成功。

对于非执行事务的远程节点，如果事务判断为执行成功，远程发送过来的数据，会被保存在本地的一个relay log里面（注意，与常规主从同步使用的relay log不是同一组），之后由从库的applier线程采用正常主从同步（目前已经支持LOGICAL_CLOCK并行执行）的方式执行掉对应的relay log。

这里有一个临界点，如果一个事务刚刚被写入relay log，还没有来得及执行掉，这时候有一个事务的执行涉及了相关的数据，那么后来的这个事务在执行阶段可以执行成功，但是必定会在提交阶段失败的。

使用建议

根据目前的状况看，GR使用的时候，应该做到以下几点以对性能优化以及减少分布式冲突。

虽然是分布式，但并非采用纯粹的随机或者轮询来对节点访问，而是采用一些分区算法，保证指定的主键必定发生指定的实例上。

这点主要目的是避免出现事务在分布式系统中的冲突，导致不可控的事务回滚。

建议的分区算法是一致性哈希，方便节点的添加删除，以及负载均衡。

控制单次事务操作数据量

即控制事务所涉及修改（增，删，改）的数据，主要原因有两点：

一是，多节点之间的冲突检验需要传输相关的数据，如果单次事务量过大，会导致单次事务的检查时间增长，由于分布式事务的全局序列性，单个慢事务会导致全局的低速。

二是，由于最终多节点的同步，还是通过每个节点自己的relay线程来执行的，如果有大事务，会导致relay线程执行不到后面的事务，导致事务延迟，并导致可能会产生的分布式事务回滚。

周边功能介绍

主要组件简介

不可用本身的发觉，是依赖消息通讯的超时决定的。即如果节点对另外的节点的消息发送超时，则认为远程节点不可用。

对于正常节点，如果认为一个其他节点不可用了，首先会标记为不可用，之后与其他节点沟通，如果确认这个节点确实其他节点都认为不可用，则实际设置为不可用节点。

如果一个节点发现自生连接不到其他所有的实例（认为其他节点全部死亡），则这个节点本身之后的事务执行，就不会采用分布式算法而是退回传统的单节点事务模式。

另外，如果同时失败节点数过多（超过一半），为了避免脑裂，分布式算法会拒绝运行，需要人工介入恢复，这也是需要注意的一点。

失败恢复

这里说的，主要把一个节点，加入到已有集群的过程，而非单实例的崩溃恢复。

-- 阶段1

第一阶段，新实例选择集群中的一个实例作为种子实例，这个种子实例会发送所有新实例到加入集群为止缺失的日志数据到新实例，这个的执行，是通过简单的主从同步日志的方式做的。

执行阶段1的期间，新实例还会一直持续接收当前正在活跃（实例加入集群后）的事务的日志，补全从种子实例没有传输的增量日志。

当种子实例传输日志完成之后，第一阶段就完毕了。

这一阶段，如果种子实例出现问题崩溃或者失败了，新实例会自动选取实例里面别的实例替代。

-- 阶段2

这一阶段，新实例合并之前的活跃事务到当前数据库，当残余的事务量接近0（新事务一直在别的实例发生，只能非常接近0而很难完全追上）的时候，实例在集群中的状态，就会被修改为ONLINE了。

mysql的GR，全局所有的实例都拥有所有的数据，也实际上需要运行所有的写入流量，如果有某一个实例相对较慢，如果时间持续下去，这个节点可能出现延迟，极端情况下，可能越追越远。

流量控制试图做到的事情是，保障整个集群节点之间，最快的节点和最慢的节点之间的事务差距不要太大。

实际需要控制的，有两个队列，一个是事务提交时候的冲突检查队列，一个是事务实际执行的relay日志队列

DDL执行

DDL先天上并不支持事务化，也就是多节点执行的时候，如果有几个节点失败，并不会导致已经执行成功的节点回滚DDL，对于DDL的执行结果需要单独验证，以避免多节点表不一致。

IP白名单

这个主要是安全方面的考虑，之允许指定来源的ip作为复制节点与集群通讯。

一些限制

使用group replication有以下一些限制。

事务写集合（Transaction write set extraction）必须打开。（这个目前与savepoint冲突，这也是导致mysqldump无法备份GR实例的原因）

对同一个对象，在集群中不同的实例上，并行地执行DDL（哪怕是相互冲突的DDL）是可行的，但会导致数据一致性等方面的错误，目前阶段不支持在多节点同时执行同一对象的DDL。

几个名词

Donor：用于节点恢复时候，传输历史binlog的节点。
Group Configuration：集群里已经配置的实例列表。
Group Membership Service：维护一致性view变更的服务，作用于节点的新增，退出，以及当前视图的维护工作。
Joiner：将要加入到集群但状态尚未恢复到ONLINE的新节点。
Seed：负责触发新节点加入集群动作的实例。
View：当前集群活跃实例的列表。

本文出自数据和云公众号，原文链接

概述：Mysql集群的方式可以是很多的，主从，一主多从，多组多从，主从的策略还可以进一步选择和配置。可以说是很灵活了。本文介绍的Replication是异步复制同步方案，分别有基于日志的还有基于GTID的。
MySQL · 引擎特性 · Group Replication内核解析之二 前文已经介绍了MySQL的Group Replication的实现机制和原理，本文就Group Replication的具体实现进行详细的阐述，以更深入的理解Group Replication的机制，在实践中更好的应用Group Replication，提升应用系统的可用性，优化其性能。
MySQL Replication 主从复制全方位解决方案 原文:MySQL Replication 主从复制全方位解决方案 1.1 主从复制基础概念 在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行，二进制日志相关信息参考：http://www.