mysqlpump的性能测试(r12笔记第89天)

作者: admin 分类: 公众号存档            2 次浏览 发布时间: 2017-06-08 23:29

公众号:杨建荣的学习笔记 · 作者:杨建荣 · 发布:2017-06-08 23:29:06 · 原文链接

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

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

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

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

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

   得到的一个基本测试结果如下,后续的测试结果会一并补上。

option real idle% dump_size(byte)
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

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

个人微信公众号,欢迎扫码关注。

admin

杨建荣,《Oracle DBA工作笔记》《MySQL DBA工作笔记》作者,dbaplus社群发起人之一,腾讯云TVP,现任竞技世界系统部经理,拥有十多年数据库开发和运维经验,目前专注于开源技术、运维自动化和性能调优

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注