沃趣QFusion vs MGR、MGC面面观

左手的ㄟ右手 2022-05-31 13:50 464阅读 0赞

沃趣 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%

详细测试数据如下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1][]

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

*  沃趣 QFusion：采用MySQL 5.7.19 主从复制
 *  MGR：采用MySQL 5.7.19 group replication
 *  MGC：采用MariaDB 10.2.12 Galera Cluster（gcs.fc\_limit = 100）

二、架构对比

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2][]

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

## 丨2.1. MGC ##

1、架构

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

Galera组件组成

*  group communication层：主要实现统一全局数据同步策略和集群内部所有事务的排序，便于生成GTID
 *  replication层：主要用于完成数据同步，由applier和slave queue组成。replication模块的效率直接影响整个集群的写入功能。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4][]

2、工作原理

写节点有更新操作时，先广播发送writeset给其他节点，其他节点certification通过之后，写节点则执行commit\_cb（其他节点执行apply\_cb和commit\_cb），否则执行rollback\_cb（其他节点certifacation丢弃数据集），如下图：   
![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5][]  
3、优缺点

优点：

*  高可用性
 *  强一致性
 *  易扩展

缺点：

*  事务需要全局验证通过，集群性能受限于性能最差的节点
 *  多点并发写入时，锁冲突严重
 *  全量拷贝数据SST，作为donor（提供同步文件的节点）的节点在同步过程中无法提供读写
 *  维护成本高，限制和注意事项较多

## 丨2.2. MGR ##

1、架构图

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

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

*  capture 追踪当前正在执行的事务的上下文。
 *  applier 执行远程事务传输到本地的日志到本地数据库。
 *  recovery 负责分布式环境下的节点恢复，以及相关的数据回追，失败处理等。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6][]

2、工作原理

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

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中，主库主机异常时自动调度一个全新主机挂载主库数据卷即可恢复，整个过程数十秒完成   
![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8][]

2、工作原理

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

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/

[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220531/e395dff0bcd0432fa35fc74e8923bb08.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220531/4d6a4f5548954eee8a9d0cead34d3234.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2]: /images/20220531/a713df2bad7149dd88be455e73ecf175.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 3]: /images/20220531/a9ff539d6b2b4bafba78808e83a7dcf7.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4]: /images/20220531/3c89e110c3474a5dab527ac24998f755.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5]: /images/20220531/5018f01d828443a6bdb1afb5fa10cc82.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6]: /images/20220531/e742cc6892e449bcac147f66c61702cc.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 7]: /images/20220531/b773636d4bfd4dfeaecb8a3326ceaf7f.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8]: /images/20220531/b448c3d7877d47089b2b994437f42e7e.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 9]: /images/20220531/ffec0c42fe81441e9f6c055d2cf6241f.png