刘伟  云和开创高级顾问

题记：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线程执行不到后面的事务，导致事务延迟，并导致可能会产生的分布式事务回滚。

周边功能介绍

主要组件简介

• capture 追踪当前正在执行的事务的上下文

• applier 执行远程事务传输到本地的日志到本地数据库

• recovery 负责分布式环境下的节点恢复，以及相关的数据回追，失败处理等

失败节点检测

只有认为无法连接的节点才会从集群中自动踢走。

机制如下：

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

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

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

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

节点状态

• ONLINE 节点状态正常，可以正常执行事务

• RECOVERING 正在接收种子节点的日志

• OFFLINE 节点之前注册了，但并不属于当前集群（可能节点已经失败）

• ERROR 恢复阶段，阶段1或者阶段2失败

• UNREACHABLE 节点不可达，一般出现在通讯超时的情况

失败恢复

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

-->阶段1

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

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

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

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

-->阶段2

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

流量控制

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

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

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

DDL执行

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

IP白名单

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

一些限制

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

1. 所有涉及的数据都必须发生在InnoDB存储引擎的表内。

2. 所有的表必须有明确的主键定义。

3. 网络地址只支持IPv4。

4. 需要低延迟，高带宽的网络。

5. 目前集群限制最多允许9个节点。

6. 必须启用binlog。

7. binlog 格式必须是row格式。

8. 必须打开gtid模式。

9. 复制相关信息必须使用表存储。

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

11. log slave updates必须打开。

12. binlog的checksum目前不支持。

13. 由于事务写集合的干扰，无法使用savepoint。

14. SERIALIZABLE 隔离级别目前不支持。

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

16. 外键的级联约束操作目前的实现并不完全支持，不推荐使用。

几个名词

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

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