沃趣QFusion vs MGR、MGC面面观

沃趣 QFusion 采用目前已经非常成熟且应用非常广泛的主从复制数据同步架构，在能保证高性能的前提下，结合商业的高性能、高可用的分布式存储QCFS实现了数据零丢失，同时沃趣科技从BIOS、硬件配置、文件系统、操作系统内核、MySQL配置参数等自底向上做了大量的整体优化，使得单位时间内的交易量进一步提升。

说到MySQL，大家平时关注得最多的不外乎就是：

• 写节点的性能上能达到多少tps/qps？为什么我们会关心它呢，因为它直接影响着单位时间内的交易量

• 读从库的复制延迟大吗？为什么我们会关心它呢，因为它直接影响着查询数据是否足够及时

• 能保证数据不丢失吗？为什么我们会关心它呢，废话，相信没有人愿意丢失数据

基于前面提到的三个问题 ，纵观MySQL业界，目前最为流行的三个发行版本(也可以叫做三个分支：官方MySQL、Percona Server、MariaDB），衍生出了不同的开源数据同步技术，国内最为流行的数据同步架构主要有如下三种：

• 主从复制架构(不用发行版本通用架构)：基于binlog日志的通用数据同步技术。在高并发压力下节点间同步数据速率最快(这里指并行复制技术)，单位时间内的交易量受其他节点的影响极小，但在主从切换时难以保证数据不丢失。

• MySQL GR(简称MGR，MySQL官方版本推出)：基于Totem协议的数据同步技术，插件式安装，MySQL官方原生插件。集群架构，提供多节点写，允许少数节点crash且能保证数据不丢失，节点间的数据同步延迟极小，但单位时间的交易量受流控影响严重

• MariaDB Galera Cluster(MGC)与Percona Xtradb Cluster(PXC)：基于Galera Cluster第三方插件库实现的数据同步技术。集群架构，提供多节点写，允许少数节点crash且能保证数据不丢失，节点间的数据同步延迟极小，但单位时间的交易量受流控和Galera插件认证效率影响严重

如上所述，目前开源的三种数据同步架构都有各自优势，也有各自明显的短板，有没有一种数据同步架构既能保证高性能，又能保证数据不丢失呢？

有！！！沃趣 QFusion 采用目前已经非常成熟且应用非常广泛的主从复制数据同步架构，在能保证高性能的前提下，结合商业的高性能、高可用的分布式存储QCFS实现了数据零丢失，同时沃趣科技从BIOS、硬件配置、文件系统、操作系统内核、MySQL配置参数等自底向上做了大量的整体优化，使得单位时间内的交易量进一步提升。

根据我们全方位的测试与对比，相比开源的数据同步解决方案，沃趣 QFusion 极具性能与稳定性优势。

口说无凭，沃趣 QFusion 相比目前开源的解决方案到底有哪些优势呢？下面我们一起从性能数据、架构原理、配置参数几个方面进行对比，一见庐山真面目！

一、性能对比

在性能测试方面，我们选用了sysbench基准测试工具，在同一套硬件环境中进行测试，全面对比了oltp、select、update、insert、delete 这5个指标值（该指标值为不同数据同步架构下的最高性能值），测试结果为：

MGR与沃趣 QFusion 相比，oltp下降32.12%、select下降5.44%、update下降24.18%、insert下降58.18%、delete下降11.44%；MGC与沃趣 QFusion 相比，oltp下降76.28%、select下降0.19%、update下降45.74%、insert下降90.49%、delete下降59.65%

详细测试数据如下：

说明：测试涉及到的版本号

• 沃趣 QFusion：采用MySQL 5.7.19 主从复制

• MGR：采用MySQL 5.7.19 group replication

• MGC：采用MariaDB 10.2.12 Galera Cluster（gcs.fc_limit = 100）

二、架构对比

从架构复杂度和原理复杂度上来说，沃趣 QFusion 采用的主从复制技术已经非常成熟(最早出现的数据同步技术)，维护成本极低(有完善的手册文档，也有相当多的使用经验可供参考)，而MGR和MGC是后出现的数据同步技术，尤其MGR是最晚出现的数据同步技术，目前几乎没有生产案例，维护成本较高--甚至MGR和MGC的错误日志就有相当一部分人看不明白。

丨2.1. MGC

1、架构

基于Galera Cluster第三方插件库实现的一个数据库集群架构，最少3个节点，最多不建议超过8个节点 

Galera组件组成

• group communication层：主要实现统一全局数据同步策略和集群内部所有事务的排序，便于生成GTID

• replication层：主要用于完成数据同步，由applier和slave queue组成。replication模块的效率直接影响整个集群的写入功能。 

2、工作原理

写节点有更新操作时，先广播发送writeset给其他节点，其他节点certification通过之后，写节点则执行commit_cb（其他节点执行apply_cb和commit_cb），否则执行rollback_cb（其他节点certifacation丢弃数据集），如下图： 

3、优缺点

优点：

• 高可用性

• 强一致性

• 易扩展

缺点：

• 事务需要全局验证通过，集群性能受限于性能最差的节点

• 多点并发写入时，锁冲突严重

• 全量拷贝数据SST，作为donor（提供同步文件的节点）的节点在同步过程中无法提供读写

• 维护成本高，限制和注意事项较多

丨2.2. MGR

1、架构图

MGR即为MySQL Group Replication的简写，基于官方原生自带的GR复制插件实现的一个数据库集群架构，最少3个节点，最多不建议超过8个节点，架构图与MGC相同；

GR组件组成：在MySQL的底层，GR增加了另外的API层来实现所需要的功能。程序结构上，GR API主要分为三部分：

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

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

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

2、工作原理

MySQL组复制是一个MySQL插件，它建立在现有的MySQL主从复制基础结构上，利用了二进制日志，基于行的日志记录和全局事务标识符等功能。基于分布式一致性算法(Paxos协议的变体)实现。原理上与Galera类似，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。Group Replication判定先提交的事务为有效事务，会在整个group里面重放，后提交的事务会直接中断，或者回滚，最后丢弃掉。 

3、优缺点

与MGC类似，但MGR还有如下限制

• 必须启用binlog，binlog 格式必须是row格式，log slave updates必须打开，binlog的checksum目前不支持

• 必须打开gtid模式

• 复制相关信息必须使用表存储

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

• SERIALIZABLE 隔离级别不支持

• 并行执行DDL可能导致数据一致性等方面的错误，目前不支持在多节点同时执行同一对象的DDL

• 外键的级联约束操作目前的实现并不完全支持

丨2.3. QFusion

1、架构图

不同数据节点之间的数据同步基于主从复制机制实现，但得益于QCFS存储，主库数据存放在QCFS中，主库主机异常时自动调度一个全新主机挂载主库数据卷即可恢复，整个过程数十秒完成 

2、工作原理

主库事务提交时，同时把数据变更写入主库自身的binlog file，并通知主库上的Binlog Dump线程有更新产生，从库的IO线程读取主库的binlog file，并存放到从库的relay log file中，然后从库的SQL线程读取relay log file解析重放应用到数据文件中，完成数据同步 

3、优缺点

优点：

主库异步写，性能与单实例媲美，且性能不受其他节点的牵制，没有MGR和MGC的众多限制

缺点：

使用异步复制在主备写业务切换中，容易导致数据丢失。但在QFusion平台中，使用"单主+QCFS存储"架构完美解决这个缺陷，一个复制集群中只需要一个节点作为写节点，其他都作为只读从节点，当主库crash之后，得益于QCFS存储，主库数据存放在QCFS中，主库主机异常时自动调度一个全新主机挂载主库数据卷即可恢复，整个过程数十秒完成且保证数据零丢失。

三、参数对比

从配置参数的复杂度来说，要成功把数据同步架构 run 起来，主从复制架构的必配参数值需要2~3个，而MGC的必配参数有近10个，MGR由于更多的使用限制原因，必配参数更是多达10个以上

丨3.1. MGC

Galera组件必须配置参数：

# 不同节点只需要修改wsrep_node_address参数为自己的IP地址即可
wsrep_on=on
wsrep_provider=/usr/local/mysql/lib/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=1G;evs.send_window=256;evs.user_send_window=128"
wsrep_cluster_name=wqglr_0001
wsrep_cluster_address=gcomm://10.10.90.167:4567,10.10.90.174:4567,10.10.90.180:4567
wsrep_node_name = physical
wsrep_node_address=10.10.90.180:4567
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth="xtrabackup:xtrabackuppass"
wsrep_slave_threads=8

丨3.2. MGR

MySQL Group Replication必须配置参数：

# 组复制限制要求参数
server_id = 3306197
log-bin = /opt/mysql/data/binlog/mysql-bin
binlog-format = ROW
binlog-checksum = NONE
master-info-repository = TABLE
relay-log-info-repository = TABLE
log_slave_updates=ON
gtid-mode = on
enforce-gtid-consistency = true
# 配置组复制参数，每个节点值需要修改group_replication_local_address为自己的IP即可
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "10.10.90.197:24901"
loose-group_replication_group_seeds= "10.10.90.197:24901,10.10.90.186:24901,10.10.90.181:24901"
loose-group_replication_bootstrap_group= off

丨3.3. QFusion

MySQL Asynchronous Replication（异步复制）必须配置参数：

#指定binlog路径和名称前缀，如果不指定路径，默认在datadir参数指定的路径下
log-bin=mysql-bin
#指定实例全局唯一server_id，如果不指定，可能碰到从库IO线程因为判断主库没有明确配置server_id而无法连接主库的BUG
server_id=1
#建议设置为row格式复制，否则在高并发场景容易导致主从数据不一致，或者从库复制报错中断
binlog_format = row

参考资料：

https://yq.aliyun.com/articles/223593

http://blog.51cto.com/wangwei007/1893703

http://blog.51cto.com/jschu/1887339

http://galeracluster.com/products/