说到MySQL,大家平时关注得最多的不外乎就是:
基于前面提到的三个问题 ,纵观MySQL业界,目前最为流行的三个发行版本(也可以叫做三个分支:官方MySQL、Percona Server、MariaDB),衍生出了不同的开源数据同步技术,国内最为流行的数据同步架构主要有如下三种:
如上所述,目前开源的三种数据同步架构都有各自优势,也有各自明显的短板,有没有一种数据同步架构既能保证高性能,又能保证数据不丢失呢?
有!!!沃趣 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 采用的主从复制技术已经非常成熟(最早出现的数据同步技术),维护成本极低(有完善的手册文档,也有相当多的使用经验可供参考),而MGR和MGC是后出现的数据同步技术,尤其MGR是最晚出现的数据同步技术,目前几乎没有生产案例,维护成本较高--甚至MGR和MGC的错误日志就有相当一部分人看不明白。
1、架构
基于Galera Cluster第三方插件库实现的一个数据库集群架构,最少3个节点,最多不建议超过8个节点
Galera组件组成
2、工作原理
写节点有更新操作时,先广播发送writeset给其他节点,其他节点certification通过之后,写节点则执行commit_cb(其他节点执行apply_cb和commit_cb),否则执行rollback_cb(其他节点certifacation丢弃数据集),如下图:
3、优缺点
优点:
缺点:
1、架构图
MGR即为MySQL Group Replication的简写,基于官方原生自带的GR复制插件实现的一个数据库集群架构,最少3个节点,最多不建议超过8个节点,架构图与MGC相同;
GR组件组成:在MySQL的底层,GR增加了另外的API层来实现所需要的功能。程序结构上,GR API主要分为三部分:
2、工作原理
MySQL组复制是一个MySQL插件,它建立在现有的MySQL主从复制基础结构上,利用了二进制日志,基于行的日志记录和全局事务标识符等功能。基于分布式一致性算法(Paxos协议的变体)实现。原理上与Galera类似,当一个事务准备提交时,会自动在group内进行原子性的广播,告知其他节点变更了什么内容/执行了什么事务。Group Replication判定先提交的事务为有效事务,会在整个group里面重放,后提交的事务会直接中断,或者回滚,最后丢弃掉。
3、优缺点
与MGC类似,但MGR还有如下限制
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个以上
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
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
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/