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

  昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试,当然只是一个开始,因为里面还有不少需要完善的部分,总体的感觉来看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 ]当然想看到更加细致的图形对比,也不是一件难的事情,得容我花点时间收集下数据,给出一个详细的对比报告。

时间: 2024-09-20 12:17:07

MySQL 5.6, 5.7并行复制测试(二)(r12笔记第10天)的相关文章

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

   对于主从延迟,其实一直以来就是一个颇有争议的话题,在MySQL阵营中,如果容忍一定的延迟的场景,通过主从来达到读写分离是个很不错的方案,但是延迟率到底有多高可以接受,新版本中的并行复制效果怎么样,在不同的版本中是否有改变,我们能否找到一些参考的数据来佐证,这一点上我们可以通过一些小测试来说明.    首先来为了基本按照同一个参考标准,我们就在同一台服务器上安装了5.6,5.7的MySQL服务,另外一台服务器上搭建了从库.    数据库版本为5.6.23 Percona分支, 5.7.17

MySQL中GTID和自增列的数据测试(r12笔记第38天)

  昨天的一篇文章,今天有不少网友向我确认一些细节,我想最近正好在看GTID的东西,可以揉在一起来说说.    GTID这个概念看似简单,实际上还是有不少的门道. 我们来从架构的设计角度来看看存在哪些场景需要考虑GTID的变化.   一主两从的架构模式下GTID的变化   我们就以一主两从的架构为基准进行阐述.在这个架构模式下我们会用到MHA的方案.    如果这个时候Master节点宕机了,MHA就会开启检查机制. 这个时候Slave 1节点就会变为新的Master,Slave 2会从Slav

MySQL和Oracle中的唯一性索引从差别(r12笔记第83天)

   今天在修复MySQL数据的时候,发现一个看起来"奇怪"的问题.   有一个表里存在一个唯一性索引,这个索引包含3个列,这个唯一性索引的意义就是通过这3个列能够定位到具体1行的数据,但是在实际中却发现这个唯一性索引还是有一个地方可能被大家忽略了.  我们先来看看数据的情况.  CREATE TABLE `test_base_data` (   `servertime` datetime DEFAULT NULL COMMENT '时间',   `appkey` varchar(64

MySQL root用户登录的几个小问题(r12笔记第67天)

  今天和同事聊了聊技术的事情,聊到BAT里面的一些高大上的系统和设计,相比总是会有些差距,不过像那样体量的公司知识沉淀很深,所以能够做好我们力所能及的事情,把它细化做好,也是一种进步和改进.    如果你老是觉得自己的环境受限,有各种KPI或者是成本的考量,做事情从下往上去推动很难,这些都是实际的困难,很多公司都是存在这样的问题的.在资源受限方面,我尤其纠结,举个有意思的小例子,如果我收到一条报警,提示数据库表空间不足了,那就添加一个数据文件呗,结果数据库层面的空间问题解决了,而马上会收到一个

Oracle和MySQL竟然可以这么写这样的SQL?(r12笔记第99天)

今天看到Franck Pachot?发了一个Twitter,意思是Oracle里的SQL还能这么写.猛一看确实让人有些意外. 禁不住诱惑,自己也尝试了一番.我现在12cR2的环境中测试了一下. Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production 尝试上面的步骤,先来看看dual表. SQL> select count(*)from dual;   COUNT(*) ----------     

MySQL · 特性分析 · LOGICAL_CLOCK 并行复制原理及实现分析

在MySQL5.7 引入基于Logical clock的并行复制方案前,MySQL使用基于Schema的并行复制,使不同db下的DML操作可以在备库并发回放.在优化后,可以做到不同表table下并发.但是如果业务在Master端高并发写入一个库(或者优化后的表),那么slave端就会出现较大的延迟.基于schema的并行复制,Slave作为只读实例提供读取功能时候可以保证同schema下事务的因果序(Causal Consistency,本文讨论Consistency的时候均假设Slave端为只

MySQL内核月报 2014.12-MySQL· 性能优化·并行复制外建约束问题

背景: mysql 主备同步是通过binlog来进行的,备库的 IO 线程从主库拉取binlog,SQL线程将拉取的binlog应用到备库,在5.6之前,备库只有一个线程应用binlog,主库的更新量大,且备库的执行效率低时,就会造成了大量从主库拉取的binlog来不及执行,因此造成了主备延迟问题.为了解决主备延迟,需要提高备库的执行效率,阿里MySQL 设计并开发了并行复制功能,所谓并行复制,指的是应用binlog的线程数量是多个的,而不是原生的单个线程,经过测试可以极大的提高复制性能(有3X

阿里RDS开发专家解析MySQL各版本并行复制

MySQL并行复制已经是老生常谈,我从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲地分享.现在再提这个话题有点"炒冷饭"的感觉.然而,又把它拎出来谈,是因为有些同学觉得"5.7的并行复制终于彻底解决了复制并发性问题".但我感觉还是有必要分析一下,这就好像大家都说没有银弹,但是又期待银弹一样. 既然要说5.7版本的并行复制,干脆顺手把各个版本的并行复制都说明一下,也好有个对比. 目录 背景 解决基本思路 MySQL5.5版本分析 MySQL5.6版本分

各版本MySQL并行复制的实现及优缺点

MySQL并行复制已经是老生常谈,笔者从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲分享,现在再提这个话题本来是难免"炒冷饭"嫌疑.    最近触发再谈这个话题,是因为有些同学觉得"5.7的并行复制终于彻底解决了复制并发性问题", 感觉还是有必要分析一下.大家都说没有银弹,但是又期待银弹..   既然要说5.7的并行复制,干脆顺手把各个版本的并行复制都说明一下,也好有个对比.便是本次分享的初衷.   [背景] 一句话说完,因为这几年太多这样文章了,