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

  • 1）写节点的性能上能达到多少tps/qps？为什么我们会关心它呢，因为它直接影响着单位时间内的交易量
  • 2）读从库的复制延迟大吗？为什么我们会关心它呢，因为它直接影响着查询数据是否足够及时
  • 3）能保证数据不丢失吗？为什么我们会关心它呢，废话，相信没有人愿意丢失数据

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

  • 1）主从复制架构(不用发行版本通用架构)：基于binlog日志的通用数据同步技术。在高并发压力下节点间同步数据速率最快(这里指并行复制技术)，单位时间内的交易量受其他节点的影响极小，但在主从切换时难以保证数据不丢失。
  • 2）MySQL GR(简称MGR，MySQL官方版本推出)：基于Paxos协议的数据同步技术，插件式安装，MySQL官方原生插件。集群架构，提供多节点写，允许少数节点crash且能保证数据不丢失，节点间的数据同步延迟较小，但单位时间的交易量受流控影响严重
  • 3）MariaDB Galera Cluster(MGC)与Percona Xtradb Cluster(PXC)：基于Galera Cluster第三方插件库实现的数据同步技术。集群架构，提供多节点写，允许少数节点crash且能保证数据不丢失，节点间的数据同步延迟较小，但单位时间的交易量受流控和Galera插件认证效率影响严重

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

• 有！！！沃趣 QFusion 采用目前已经非常成熟且应用非常广泛的主从复制数据同步架构，在能保证高性能的前提下，结合商业的高性能、高可用的分布式存储QCFS实现了数据零丢失，同时我们从BIOS、硬件配置、文件系统、操作系统内核、MySQL配置参数等自底向上做了大量的整体优化，使得单位时间内的交易量进一步提升。根据我们全方位的测试与对比，相比开源的数据同步解决方案，沃趣 QFusion 极具性能与稳定性优势。

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

1、性能对比

• 在性能测试方面，我们选用了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%

• 详细测试数据如下

• PS：测试涉及到的版本号
  • 沃趣 QFusion：采用MySQL 5.7.19 主从复制
  • MGR：采用MySQL 5.7.19 group replication
  • MGC：采用MariaDB 10.2.12 Galera Cluster（gcs.fc_limit = 100）

2、架构对比

• 从架构复杂度和原理复杂度上来说，沃趣 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中，主库主机异常时自动调度一个全新主机挂载主库数据卷即可恢复，整个过程数十秒完成且保证数据零丢失

3、参数对比

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

3.1. MGC

• Galera组件必须配置参数

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

3.2. MGR

• MySQL Group Replication必须配置参数

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

3.3. QFusion

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

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

• 参考资料：

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28218939/viewspace-2151197/，如需转载，请注明出处，否则将追究法律责任。