[译]备份性能对比：mysqldump vs MySQL Shell组件 vs mydumper vs mysqlpump vs XtraBackup

原创晨辉 2022-03-14

4166

原文地址：https://www.percona.com/blog/dump-performance-comparison-mysqldump-vs-mysql-shell-utilities-vs-mydumper/
原文作者：Vinicius Grippa
复制

在这篇博文中，我们将对比使用 mysqldump，MySQL Shell功能（Instance Dump),mysqlpump,mydumper和 Percona XtraBackup不同备份工具对MySQL数据库的备份性能。所有这些可选项在整个社区都是开源、免费使用的。
现在开始，让我们看看测试结果：

基准测试（Benchmark) 结果
我在一个配置了128GB内存，32颗虚拟CPU，两块NVMe协议的600GB 磁盘（一块用于备份，另一块用于存放MySQL数据）的一套m5dn.8xlarge实例上运行的benchmark。MySQL的版本是8.0.26，配置了89GB的buffer pool,20GB的redo log,测试数据库数据大小为 177GB（详细细节在下面）

我们获得如下图表的结果:

如果我们只分析多线程备份工具，那么图表结果如下：

如我们所见，每个工具我都执行了三次，为了测试 16，32，64个线程时的性能数据。对于mysqldump的异常是因为它不支持并发，只能使用单线程。
我们获得了一些有趣的结果：
当我们使用zstd压缩时，mydumper 在性能方面真的很出色。这个功能在不久前刚添加（MyDumper 0.11.3）
当mydumper使用gzip压缩时， MySQL Shell是最快的备份工具，排第三的是Percona XtraBackup。
mysqlpump 是第四快，紧随其后的是使用gzip压缩选项的mydumper.
mysqldump 是经典的、保守的方式去实施备份，它的速度也是最慢的。
对于有更多CPU的服务器，意味着并发能力也可以提升，这也给了能支持多线程备份工具更多的优势。
硬件和软件规格
以下是基准测试的规格:
32 CPUs
128GB 内存
2x NVMe disks 600 GB
Centos 7.9
MySQL 8.0.26
MySQL shell 8.0.26
mydumper 0.11.5 – gzip
mydumper 0.11.5 – zstd
Xtrabackup 8.0.26

my.cnf配置参数如下:

[mysqld]
innodb_buffer_pool_size = 89G
innodb_log_file_size = 10G
复制

性能测试：
在这个测试中，我使用的sysbench去生成数据。为了加载数据，我选择了tpcc的方法：

$ ./tpcc.lua  --mysql-user=sysbench --mysql-password='sysbench' --mysql-db=percona --time=300 --threads=64 --report-interval=1 --tables=10 --scale=100 --db-driver=mysql prepare
复制

在开始对比之前，我执行了一次mysqldump用来预热缓存（结果已被废弃），否则的话测试会有偏差，因为第一次备份必须从磁盘读取数据而不是从内存。
当准备工作都已就绪，我开始使用如下操作来执行mysqldump:

$ time mysqldump --all-databases --max-allowed-packet=4294967295 --single-transaction -R --master-data=2 --flush-logs | gzip > /backup/dump.dmp.gz
复制

Mysql Shell 组件:

$ mysqlsh
MySQL JS > shell.connect('root@localhost:3306');
MySQL localhost:3306 ssl test JS > util.dumpInstance("/backup", {ocimds: true, compatibility: ["strip_restricted_grants","ignore_missing_pks"],threads: 16})
复制

mydumper:

$ time mydumper  --threads=16  --trx-consistency-only --events --routines --triggers --compress --outputdir /backup/ --logfile /backup/log.out --verbose=2
复制

备注：要使用zstd的话需要下载zstd的版本包，命令行是一样的。
mysqlpump:

$ time mysqlpump --default-parallelism=16 --all-databases > backup.out
复制

xtrabackup:

$ time xtrabackup --backup --parallel=16 --compress --compress-threads=16 --datadir=/mysql_data/ --target-dir=/backup/
复制

分析结果
这结果给了我们什么启发呢？
并行方法有相似的性能吞吐，mydumper工具在使用zstd压缩时比使用gzip压缩直接降低了50%的时间，因此当使用mydumper时压缩方式对备份性能产生了很大的差异。
对于 MySQL Shell 的dumpInstance组件，一大优势是备份的数据既包括文本格式也包括二进制格式，而且默认使用zstd压缩方式。像 mydumper一样，它使用多个文件来存储数据，这样有一个好的压缩率。
XtraBackup 获得了第三点排名，和MySQL shell只相差了几秒。XtraBackup 的主要优势是它的弹性功能，比如支持PITR （基于时间、点的恢复功能）和加密功能。
接下来，mysqlpump 是比使用gzip方式的mydumper更高效，不过只占很小的优势。两者都是逻辑备份，工作方式是一样的。我测试了使用压缩方式的mysqlpump，不过结果是一样的，因此我没有将这个加入到图表中。一个可能的原因是mysqlpump流将数据只备份到单个文件。
最后，对于mysqldump,我们可以说，它具有最可预测的行为，并且在不同的运行中具有相似的执行时间.缺乏并行和压缩功能是mysqldump的一个劣势；然而，因为它是最早出现在MySQL版本中的，基于Percona的例子，它一直都是用作逻辑备份的方法。