mysqlpump和mysqldump的性能大比拼(r12笔记第90天)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 昨天测试了一下mysqlpump,今天来把剩下的补充完成,算是一个小的系列。 mysqlpump 在MySQL 5.7中做逻辑备份恢复有了一个新的工具mysqlpump,如果你掌握了mysqldump,那么使用mysqlpump就是分分钟的事情,因为很多参数都是很相似的,可以理解它是mysqldump的加强版,一个亮点就是有了并行的选项,使得数据备份的性能更加强大。
昨天测试了一下mysqlpump,今天来把剩下的补充完成,算是一个小的系列。

mysqlpump

在MySQL 5.7中做逻辑备份恢复有了一个新的工具mysqlpump,如果你掌握了mysqldump,那么使用mysqlpump就是分分钟的事情,因为很多参数都是很相似的,可以理解它是mysqldump的加强版,一个亮点就是有了并行的选项,使得数据备份的性能更加强大。

  有一点值得说明的是,为了保证数据一致性,我们一般备份都会使用--single-transaction的选项,在5.7.11以前,mysqlpump和并行参数是有冲突的,在这个版本之后做了修复。

  但是mysqlpump到底怎么样呢,我在5.7.17的版本中做了一些简单的测试,可以看出一些性能的差异。

  而mysqldump是大家最耳熟能详的工具了,如果没用过,都不好意思说自己会MySQL,这样一个工具和Oracle里的exp工具一般,经典而且功能丰富。  

测试环境说明

   为了尽可能保证导出的数据备份能够占用少的磁盘空间,我们经常会使用gzip来压缩,我们就分了几个场景来对比压缩,不压缩,开启并行后的数据备份的性能差异。

   我选取的数据集大小在30G左右。含有5个数据库,单表数据量在200万以上,单库的表数量在10个以上。

数据备份的测试结果

数据备份的测试场景自己做得多一些,当然备份层面的压缩暂时还没有测完整,其它的场景


option real idle% dump_size(byte)
mysqlpump compress=false 6m52.232s 85.92 26199028017

compress=false|gzip 43m12.574s 90.72 12571701197

compress=true 19m24.541s 80.48 26199028017

compress=true |gzip 43m12.515s 84.94 12571200219

parallelism=4  5m30.005s 76.43 26199028017

parallelism=4 |gzip 42m41.433s 90.51 12575331504

parallelism=8 4m44.177s 66.73 26199028017

parallelism=8 |gzip 42m50.417s 90.38 12574079375

parallelism=16 5m19.060s 90.38 26199028017

parallelism=16 |gzip 42m50.939s 89.65 12577618359

parallelism=32  5m10.220s 89.23 26199028017

parallelism=32 |gzip 45m47.022s 89.7 12577618359
mysqldump compress=false 9m19.785s 87.33 26176062499

compress=false |gzip 43m23.036s 90.97 12524413896

compress=true 37m42.052s 90.1 26176062499

compress=true |gzip 43m17.755s 85.89 12524413896

compress=true  38m55.968s 90.22 26176062499

compress=true |gzip 43m1.672s 85.77 12524413896

可以看到默认来说,导出一个30G左右的dump需要近7分钟,而启用了并行之后,并行度为4的时候,导出时间是5分半,提升了1.5分钟(20%),并行度为8之后提升了2分钟左右(30%)。而在系统层面做了压缩的时候,压缩率达到了近48%,而并行度在更大的时候,备份速度就差别不大了,一来也和CPU的情况有关,整体来说并行的效果还是不错的。在compress=true只是在服务端客户端交互中使用数据包压缩,最后的备份集大小是没有任何改变的。后续会测试使用不同的压缩算法,备份的性能差异。


系统层面压缩备份的情况

如果备份不通过gzip管道来压缩,而是直接生成备份压缩,效率如果呢。一个26G左右的备份,gzip压缩的时间大概是43m18.974s,其实还真不短,比预想的长多了。

数据导入效率

数据的导入,我就简单测试了两个场景,mysqlpump并行备份导出,导入,mysqldump备份导出导入

mysqlpump export  parallelism=4 7m

import 85m4.574s
mysqldump export  9m8.420s

import 97m9.760s


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
4月前
|
SQL 关系型数据库 MySQL
【MySQL 慢查询秘籍】慢SQL无处遁形!实战指南:一步步教你揪出数据库性能杀手!
【8月更文挑战第24天】本文以教程形式深入探讨了MySQL慢SQL查询的分析与优化方法。首先介绍了如何配置MySQL以记录执行时间过长的SQL语句。接着,利用内置工具`mysqlslowlog`及第三方工具`pt-query-digest`对慢查询日志进行了详细分析。通过一个具体示例展示了可能导致性能瓶颈的查询,并提出了相应的优化策略,包括添加索引、缩小查询范围、使用`EXPLAIN`分析执行计划等。掌握这些技巧对于提升MySQL数据库性能具有重要意义。
350 1
|
5月前
|
分布式数据库 索引
Greenplum实用技巧
以上是一些基本的Greenplum实用技巧,希望对你有所帮助。
46 1
|
6月前
|
存储 关系型数据库 MySQL
技术笔记:MySQL数据库优化详解(收藏)
技术笔记:MySQL数据库优化详解(收藏)
60 0
|
7月前
|
存储 固态存储 关系型数据库
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(系统底层优化篇)(一)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(系统底层优化篇)
81 1
|
7月前
|
存储 缓存 关系型数据库
掌握MySQL数据库这些优化技巧,事半功倍!
掌握MySQL数据库这些优化技巧,事半功倍!
|
7月前
|
SQL 数据库 数据库管理
sql数据库代码大全
sql数据库代码大全
|
7月前
|
缓存 网络协议 关系型数据库
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(系统底层优化篇)(二)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(系统底层优化篇)
74 0
|
7月前
|
缓存 关系型数据库 MySQL
史上最全MySQL 大表优化方案(长文)
史上最全MySQL 大表优化方案(长文)
1571 0
|
7月前
|
存储 小程序 前端开发
前端知识笔记(四十六)———什么是小程序,什么是数据库
前端知识笔记(四十六)———什么是小程序,什么是数据库
57 0
教你几招快速创建MySQL千万级数据,学习上百种优化技巧
如果你打算好好学习一下 MySQL,性能优化肯定是绕不过去一个问题。当你撸起袖子准备开始的时候,突然发现一个问题摆在眼前,本地数据库中没那么大的数据量啊,几条数据优化个毛线啊。生产库里数据多,但谁敢直接在生产环境动手啊,想被提前优化吗?