微信号:InsideMySQL

介绍:MySQL数据库发烧友群;《MySQL技术内幕》系列书籍官方帐号;不谈小道消息,只关注MySQL相关技术

MySQL Group Replication性能测试,星辰大海还是前路茫茫?

2016-12-29 19:43 姜承尧


姜承尧

IT界最会讲故事的男同学




抽的闲完成了MySQL Group Replication首轮性能测试,不敢独享,放上来给小伙伴们一起瞅瞅。在之前的文章Galera将死——MySQL Group Replication正式发布中,已经对MGR给出了简单的介绍,同时也提供了一些官方的性能测试报告。


其实大部分同学更关心的是在自己的生产环境系统上,MGR的表现。比如一个云服务器环境,服务器配置很普通,网络也仅是普通千兆的网络。所以这次测试找了网易蜂巢云主机作为测试服务器,配置较为普通,在这样的测试下是否能复现Oracle官方的测试结果呢?(注,测试为全内存CPU-bound测试,这样对MGR的负载要求最高)


CPU:4VCPU×4ECU 

内存:16G

网卡:千兆网络(测试环境)

存储:SSD 4K IOPS:10000 



性能基准测试采用大家所熟知的sysbench工具,Oracle官方的MGR测试也是使用了此工具。测试使用强持久化配置,即所有日志相关的参数设置都为1,确保每次提交日志落盘。配置参数具体见:MySQL最优配置文件模板·2016-11-28


首先进行读写测试,测试脚本为oltp.lua,此测试的每个事务由18条SQL语句组成,其中SELECT操作14个,UPDATE操作2个,INSERT和DELETE操作分别为1个。在这样的简单测试场景下:




测试对比了原生的MySQL异步复制,1个结点的MGR和3个结点的MGR。从测试报告可以发现在读写比例14:4的场景下,MGR的性能与异步复制几乎一样,性能损耗仅在8.8%(对比3结点MGR)。而结点数增加并不会导致性能下降,3个结点的MGR仅比1个结点的MGR性能损耗在1.8%。这与官方的性能测试结论非常一致。更重要的是,通过上述3个结点组成的MGR集群,MySQL数据库能做到强一致的金融级数据库要求标准。


第二组测试使用sysbench的纯更新操作,也就是全部操作都是写操作,每次提交需要落盘,并且MGR集群中大部分结点需要接受到日志才能提交,测试脚本为:update_non_index.lua。




纯更新操作的测试结果开始时有些出乎意料,3结点MGR的性能只有异步复制的1/12(已打开MTS多线程并行回放功能)。默认MGR要求集群中的结点基本不能有延迟(lag),所以当发生结点不能即使回放时,会进行流控(flow control)。这都可以由参数控制,参数group_replication_flow_control_mode甚至可以用来关闭限流功能。




将参数group_replication_flow_control_mode设置为DISABLED时,性能出现了较大的提升,这符合之前的预期,平均性能为原异步性能的50%。但切记,这时SECONDARY集群的数据是有延时的。


接着我并没有去调整流控的相关参数,而是把目标放入到了压缩参数group_replication_compression_threshold。将其设置为100表示对发送的网络消息(writeset)大于100字节的进行压缩,从而提升性能。从上述测试也可以发现性能有了较大的提升,平均性能为原异步性能的35%。这或许可以推测,当网络调整为万兆网络时,MGR的性能还能有进一步的提升



上述测试使用的GR模式为Single-Primary Mode,即写入在单个结点,这也是MGR默认的配置。在上述测试配置下,基本与官方的性能测试结果一致。


要测试Multi-Primary Mode是比较麻烦的一件事情,因为现在是乐观提交,可能在提交时发生失败。所以在sysbench上直接跑Multi-Primary Mode测试,可能会遇到类似如下的错误:


Error 1180 Got error 149 during COMMIT


这是因为Certification时发现了冲突,但是sysbench工具本身目前还未处理这部分的异常,后续我着手修复这个问题。不过sysbench跑Multi-Primary Mode并不会有一个很好的结果,因为热点太过集中,会导致提交失败很多,或许反而会导致了性能的下降。


Oracle官方的Multi-Primary Mode测试是在每个结点上,对不同的sbtest库进行测试,即这样可以避免sysbench工具的问题,同时,这样也减少了冲突的可能性。切记,Multi-Primary Mode一定要避免热点数据冲突的场景


当然,在测试中还发现一个问题,即当前MGR并不能很好的支持大事务的操作,这时会导致整个集群出错,比如我执行下面的SQL:


(root@localhost) [sbtest2]> insert into sbtest1 select * from sbtest.sbtest1 limit 1000000;   ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.


(root@localhost) [sbtest2]> select * from  

performance_schema.replication_group_members\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

   MEMBER_ID: c0bb60f8-ae2a-11e6-8b1f-fa163e30f9a2

 MEMBER_HOST: test-1

 MEMBER_PORT: 3306

MEMBER_STATE: ERROR

1 row in set (0.00 sec)


总体来看,MGR的第一个GA版本的确仅适合用来熟悉,还需要给官方反馈更多的意见来完善。但正如我之前的文章说的那样,开弓没有回头箭,未来MGR必将成为MySQL一个重要的企业特性。而我们要做的,或许只是等待,因为:


陪伴是最长情的告白


很多粉丝还没有养成阅读后点赞和转发的习惯,希望大家在阅读后顺便点赞与转发,以示鼓励!长期坚持原创真的很不容易,多次想放弃。坚持是一种信仰,专注是一种态度!




猜你喜欢


 
InsideMySQL 更多文章 年薪50万?那你得先知道每天凌晨三点的样子 原谅我这么幼稚,所以才会喜欢你这麼久 #MySQL# 为什么我不再看好MariaDB 这个圣诞节,约上女神,嘿嘿嘿...... MariaDB插上大数据的翅膀?——可能只是一厢情愿
猜您喜欢 iOS图片加载速度极限优化—FastImageCache解析 SSL证书配置 UXCore:从企业系统而来,为了更多的企业系统 “八亿件衬衫换架飞机”,中国制造还是廉价代名词吗 | 品牌新事 深度学习2015年文章整理(CVPR2015)