MySQL Shell速度测试 _数据库_博客_测评&博客

我们将比较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万条记录。

${xunruicms_img_title}$

测试案例一

在这种情况下，我们将使用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进行完整备份。

例

${xunruicms_img_title}$

整个数据库的转储（与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实用程序将备份文件加载到另一个独立主机上。我们已经将备份文件移到了目标服务器。让我们开始还原过程。

例

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

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

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

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

物理备份

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

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