MySQL Shell速度测试

MySQL Shell 测试 mysqldump
2021-01-14 10:07:03
316 21 0

我们将比较mysqldump和MySQL Shell实用工具的备份和恢复速度。

以下工具用于速度比较:

  • mysqldump

  • util.dumpInstance

  • util.loadDump

硬件配置

两台具有相同配置的独立服务器。

服务器1

   * IP:192.168.33.14

   * CPU:2核心

   * RAM:4 GB

   *磁盘:200 GB SSD

服务器2

   * IP:192.168.33.15

   * CPU:2核心

   * RAM:4 GB

   *磁盘:200 GB SSD

工作量准备

在服务器1(192.168.33.14)上,我们已加载约10 GB数据。

现在,我们想将数据从服务器1(192.168.33.14)还原到服务器2(192.168.33.15)。

MySQL设置

MySQL版本:8.0.22

InnoDB缓冲池大小:1 GB

InnoDB日志文件大小:16 MB

二进制记录:开

我们使用sysbench加载了5000万条记录。

MySQL Shell速度测试

测试案例一

在这种情况下,我们将使用mysqldump命令进行逻辑备份。

例 

[root@centos14 vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf  --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events  --set-gtid-purged=OFF  --all-databases  |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gz

start_time = 2020-11-09 17:40:02

end_time = 2020-11-09 37:19:08

转储所有大约10GB的数据库花了将近20分钟19秒。

测试案例二

现在让我们尝试使用MySQL Shell实用程序。我们将使用dumpInstance进行完整备份。

例 

MySQL Shell速度测试

整个数据库的转储(与mysqldump所使用的数据相同)总共花费了1分27秒,并且它还显示了其进度,这对于了解已完成多少备份非常有帮助。它给出了执行备份所花费的时间。

并行性取决于服务器中的内核数量。在我的情况下,大约增加价值不会有帮助。(我的机器有2个核心)。

恢复速度测试 

在还原部分,我们将在另一台独立服务器上还原mysqldump备份。备份文件已使用rsync移动到目标服务器。

测试用例1 

例 

[root@centos15 vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -p

恢复10GB数据大约需要16分26秒。

测试案例2 

在这种情况下,我们使用mysql shell实用程序将备份文件加载到另一个独立主机上。我们已经将备份文件移到了目标服务器。让我们开始还原过程。

例 

MySQL Shell速度测试

恢复10GB数据花费了大约40分钟6秒。

现在,让我们尝试禁用重做日志并使用mysql shell实用程序开始数据导入。

MySQL Shell速度测试


禁用重做日志后,平均吞吐量提高到2倍。

注意:请勿在生产系统上禁用重做日志记录。它允许在禁用重做日志记录的同时关闭服务器并重新启动,但是在禁用重做日志记录的情况下服务器意外停机会导致数据丢失和实例损坏。

物理备份 

您可能已经注意到,即使是多线程的逻辑备份方法,即使对于我们对其进行测试的小型数据集,也非常耗时。这就是为什么ClusterControl提供基于文件复制的物理备份方法的原因之一-在这种情况下,我们不受处理逻辑备份的SQL层的限制,而是受硬件的限制-磁盘读取文件的速度和网络在数据库节点和备份服务器之间传输数据的速度。

ClusterControl提供了不同的方法来实施物理备份,哪种方法可用取决于群集类型,有时甚至取决于供应商。让我们看一下由ClusterControl执行的Xtrabackup,它将在我们的测试环境中创建数据的完整备份。


这次我们将创建临时备份,但是ClusterControl允许您也创建完整的备份计划。

在这里,我们选择备份方法(xtrabackup)以及将从中进行备份的主机。我们还可以将其本地存储在节点上,也可以将其流式传输到ClusterControl实例。此外,您可以将备份上传到云(支持AWS,Google Cloud和Azure)。

备份大约需要10分钟才能完成。这里是来自cmon_backup.metadata文件的日志。

MySQL Shell速度测试

现在,让我们尝试使用ClusterControl进行相同的还原。ClusterControl>备份>恢复备份 。

在这里,我们选择还原备份选项,它还将支持基于时间和日志的还原。

在这里,我们选择备份文件的源路径,然后选择目标服务器。您还必须确保可以使用SSH从ClusterControl节点访问此主机。

我们不希望ClusterControl设置软件,因此我们禁用了该选项。恢复后,它将保持服务器运行。

恢复10GB数据大约需要4分18秒。Xtrabackup不会在备份过程中锁定数据库。对于大型数据库(100+ GB),与mysqldump / shell实用程序相比,它提供了更好的还原时间。正如我的一位同事在其博客中所解释的那样,lusterControl还支持部分备份和还原:部分备份和还原。

结论

每种方法都有其优点和缺点。如我们所见,没有一种方法可以最好地满足您的所有需求。我们需要根据生产环境和目标恢复时间来选择工具。


作者介绍

用微信扫一扫

收藏