前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL 5.6, 5.7并行复制测试(二)(r12笔记第10天)

MySQL 5.6, 5.7并行复制测试(二)(r12笔记第10天)

作者头像
jeanron100
发布2018-03-21 15:11:47
1.1K0
发布2018-03-21 15:11:47
举报

昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试,MySQL 5.6, 5.7并行复制测试(r12笔记第9天),当然只是一个开始,因为里面还有不少需要完善的部分,总体的感觉来看MySQL 5.7里的并行复制改进很大,能够极大提高效率,充分利用资源。

那我们来简单回顾一下MySQL的复制里的一些事情,然后继续展开测试。

首先借丁奇大师总结的一个经典的主从复制的流程图来展开。

整个复制的流程中,看似存在多个节点会存在延迟的可能,而如果把这些工作都细化,那么就会有一个很本质的原因,那就是在主库端的更新是多线程,而从库端更新是单线程。

这样一个看似“存在即合理”方案在MySQL 5.6以前都是这么做的。最早的复制和statement格式做斗争,过了改进,有了row格式,也算是复制方向上的一大改进,而在MySQL 5.6中引入了并行复制,这一点能够缓和原本的复制瓶颈。

但是复制的效率提升不是严格意义上质的飞跃,算是一个开篇,因为支持的是数据库级别的,如果直接多线程是否可以,这个按理说是一个很常规的思路,为什么MySQL迟迟没有推出好的方案来。

多线程存在一些待解决的难题,其中之一就是语句的顺序无法保证,无论如何,日志都是需要顺序写,在源端是多线程并发操作,而映射到日志中,必然是一个顺序的记录方式,而这个操作到了从库,也只能老老实实的按照顺序来应用,如果采用多线程就得尤其注意这个顺序,我们可以逐步来细分,首先对于同一个表的更新只能按照顺序来同步,而这个粒度可以逐步细分,比如数据库级,表级等,目前MySQL 5.6中是按照数据库级来做的,当然这个粒度还是有些粗。在5.7就全面改进了。

当然我们在开始具体的测试之前,我简单说一下我们量血压的场景,一般都会有一个收缩压,舒张压的指标,对于主从复制而言,我突然想到了这一点,我觉得还是有可以借鉴的地方。

比如我昨天测试的而一个图,是MySQL 5,6,5.7单线程,多线程的延迟对比图。

其实这个图我感觉没有画完,因为大批量的事务并发处理,必然会导致延迟,比如有10分钟的高强度并发,那么10分钟后延迟不是立即消失的,从库得慢慢消化这个延迟的数据,这个时间我们也需要关注,至于主从一致后的延迟回落到底是什么样,我想只是看这个图可能还看不出个所以然,所以想到了这一点,我就继续补充了一下测试的场景,调整了时间。

下面这个图花了我不少的时间去收集数据,整理。

中间红色的箭头就是在指定的时间范围的加压测试,而右边的部分则是延迟回落的一个过程,可以很清晰的看到,对于从库的延迟在加压完成后,延迟依旧会逐步增长,达到一个峰值后,迅速回落,回落的过程来看,MySQL 5.6中的单线程,多线程,和MySQL 5.7中的测试情况大体相似,从耗时情况和延迟回落的趋势,基本都是相似的,而MySQL 5.7的并行复制相比而言就是一个亮点,数据加压后的延迟回落极快,整个过程耗时要低很多。

当然这个图例也反映出来一些问题,那就是MySQL 5.6的单线程和多线程的结果几乎一样,这就对了,这就错了。对了是由此可以看出在这个测试场景中,并行复制没有派上用场,错了的原因是测试的场景还可以继续改进,可以更有针对性。

怎么改进呢,因为5.6中是数据库级的复制,所以我们可以建立多个数据库,然后在从库开启并行复制来改进,对比测试。

怎么能够快速看到一个效果呢。

我们继续开启sysbench的加压测试,使用pt工具同步检测延迟,花几分钟就可以看出差别来,比如我们首先建立4个数据库,每个数据库下创建10个表。

mysqladmin create sysbenchtest1

初始化一部分数据,对于sysbenchtest1如此,其它的几个数据库也是类似的操作。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30 prepare

然后开启sysbench测试。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30 --time=300 run

查看延迟的情况:

pt-heartbeat h='10.127.128.78',u='pt_checksum',p='pt_checksum',P=3307 -D sysbenchtest --table=heartbeat --monitor --master-server-id=3307 --frames=5s --interval=5

几个简单的对比就可以说明。

开启并行复制模式时,延迟如下:

0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ]

然后修改参数slave_parallel_workers为0,切换回单线程模式,延迟开始加大。

1.00s [ 0.20s ] 0.00s [ 0.20s ] 2.00s [ 0.60s ] 0.00s [ 0.60s ] 1.00s [ 0.80s ] 0.00s [ 0.60s ] 0.00s [ 0.60s ] 0.00s [ 0.20s ] 0.00s [ 0.20s ] 1.00s [ 0.20s ]

再次切换回并行复制模式,延迟逐渐减低,并回复平稳。

0.00s [ 0.40s ] 0.00s [ 0.20s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.01s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.20s ] 0.00s [ 0.20s ]

当然想看到更加细致的图形对比,也不是一件难的事情,得容我花点时间收集下数据,给出一个详细的对比报告。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-03-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档