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

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:   昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试,当然只是一个开始,因为里面还有不少需要完善的部分,总体的感觉来看MySQL 5.7里的并行复制改进很大,能够极大提高效率,充分利用资源。

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

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

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

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

图片.png

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

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

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

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

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

654ac0d2-de76-4632-8748-58b72020a9d5.png

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

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

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

      当然这个图例也反映出来一些问题,那就是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 ]当然想看到更加细致的图形对比,也不是一件难的事情,得容我花点时间收集下数据,给出一个详细的对比报告。


相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
30天前
Mybatis+mysql动态分页查询数据案例——测试类HouseDaoMybatisImplTest)
Mybatis+mysql动态分页查询数据案例——测试类HouseDaoMybatisImplTest)
20 1
|
30天前
|
Java 关系型数据库 数据库连接
Mybatis+MySQL动态分页查询数据经典案例(含代码以及测试)
Mybatis+MySQL动态分页查询数据经典案例(含代码以及测试)
24 1
|
2天前
|
关系型数据库 MySQL 中间件
【MySQL实战笔记】07 | 行锁功过:怎么减少行锁对性能的影响?-02 死锁和死锁检测
【4月更文挑战第19天】在高并发环境下,死锁发生在多个线程间循环等待资源时,导致无限期等待。MySQL中,死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务,而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题,可以暂时关闭死锁检测(风险是产生大量超时),控制并发度,或通过分散记录减少锁冲突,例如将数据分拆到多行以降低死锁概率。
17 1
|
11天前
|
存储 关系型数据库 MySQL
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
【4月更文挑战第9天】InnoDB数据库使用B+树作为索引模型,其中主键索引的叶子节点存储完整行数据,非主键索引则存储主键值。主键查询只需搜索一棵树,而非主键查询需两次搜索,因此推荐使用主键查询以提高效率。在插入新值时,B+树需要维护有序性,可能导致数据页分裂影响性能。自增主键在插入时可避免数据挪动和页分裂,且占用存储空间小,通常更为理想。然而,如果场景仅需唯一索引,可直接设为主键以减少查询步骤。
13 1
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
|
13天前
|
存储 SQL 关系型数据库
【MySQL实战笔记】03.事务隔离:为什么你改了我还看不见?-02
【4月更文挑战第7天】数据库通过视图实现事务隔离,不同隔离级别如读未提交、读已提交、可重复读和串行化采用不同策略。以可重复读为例,MySQL使用多版本并发控制(MVCC),每个事务有其独立的视图。回滚日志在无更早视图时被删除。长事务可能导致大量存储占用,应避免。事务启动可显式用`begin`或设置`autocommit=0`,但后者可能意外开启长事务。建议使用`autocommit=1`并显式管理事务,若需减少交互,可使用`commit work and chain`。
29 5
|
16天前
|
SQL 存储 关系型数据库
【MySQL实战笔记】02.一条SQL更新语句是如何执行的-2
【4月更文挑战第5天】两阶段提交是为确保`redo log`和`binlog`逻辑一致,避免数据不一致。若先写`redo log`, crash后数据可能丢失,导致恢复后状态错误;若先写`binlog`,crash则可能导致重复事务,影响数据库一致性。一天一备相较于一周一备,能缩短“最长恢复时间”,但需权衡额外的存储成本。
16 1
|
1月前
|
iOS开发
iOS自动混淆测试处理笔记
iOS自动混淆测试处理笔记
12 0
|
1月前
|
算法 测试技术 开发者
软件质量测试笔记-合工大
软件质量测试笔记-合工大
101 1
|
16天前
|
关系型数据库 MySQL 数据库
mysql卸载、下载、安装(window版本)
mysql卸载、下载、安装(window版本)
|
5天前
|
关系型数据库 MySQL 数据库
《MySQL 简易速速上手小册》第1章:MySQL 基础和安装(2024 最新版)
《MySQL 简易速速上手小册》第1章:MySQL 基础和安装(2024 最新版)
28 4

热门文章

最新文章