Question

在我的cronjobs中，我每晚都会制作一个完整的mysqldump 我的数据库在20个表中有1.5GB的总数据几乎每张桌子都有索引。

我做这样的备份：

mysqldump --user=user  --password=pass  --default-character-set=utf8 database
            --single-transaction| gzip > "mybackupfile"

我做了2个月。这个过程需要将近1.5分钟，持续2个月。

上周我的托管公司改变了我的服务器。服务器更改后，此过程开始长达5分钟。我告诉服务器公司，他们将CPU从4GHz增加到6GHz，因此mysqldump进程变为3,5分钟。然后他们增加到12 GHz。但这并没有改变表现。

我使用hdparm检查了我的共享SSD磁盘性能。它是70 MB /秒。所以我再次抱怨所以他们把我的硬盘改成了另一个。硬盘读取速度变为170 MB /秒。所以mysqldump进程变成了3分钟。

但是持续时间远远超过以前的值。这种性能下降的原因是什么？我该如何找出问题？

（服务器是Centos 6.4,12 GHz CPU，8 GB RAM）

编辑：我的公司再次更换了服务器，但我仍然遇到同样的问题。旧服务器有3.5分钟的备份时间，现在新服务器有5分钟的时间。压缩时的结果文件为820 MB，解压缩时为2.9 GB。

我试图找出导致此转储缓慢的原因。

转储过程于11:24:32开始，于11:29:40停止。你可以从截图＆＃39;时间戳。

截图：

hdparm结果：

/dev/sda2:
 Timing cached reads:   3608 MB in  1.99 seconds = 1809.19 MB/sec
 Timing buffered disk reads: 284 MB in  3.00 seconds =  94.53 MB/sec

/dev/sda2:
 Timing cached reads:   2120 MB in  2.00 seconds = 1058.70 MB/sec
 Timing buffered disk reads: 330 MB in  3.01 seconds = 109.53 MB/sec

Answer 1

显而易见的是，最近几个月数据量是否增加。大多数数据库驱动的应用程序随时间收集更多数据，因此数据库不断增长如果您仍然拥有夜间备份的副本，我会查看文件大小，看看它们是否一直在稳步增长。

另一种可能性是您在备份时有其他进程正在执行读取查询。默认情况下，Mysqldump会在数据库上创建一个读锁定，以确保数据的一致快照。但这并不会阻止读取查询。如果仍有查询在运行，这可能会争夺CPU和磁盘资源，并自然会减慢速度。

或者在同一台服务器上竞争资源的MySQL之外还有其他进程。

最后，正如@andrew在上面评论的那样，同一物理服务器上可能还有其他虚拟机，竞争物理资源。这超出了您的控制范围，甚至无法在虚拟机中测试。它由托管公司来管理虚拟机的均衡分配。

问题的开始与您的托管公司将服务器移动到另一台主机的事实相吻合，这使得他们将您带到一个更加繁忙的主机上。也许他们正试图将更多虚拟机集中到一台主机上以节省机架空间或其他东西。这不是StackOverflow可以为您解决的问题 - 您应该与托管公司联系。

索引的数量或大小在备份期间并不重要，因为mysqldump只是从每个表执行SELECT *，并且这是一个表扫描。没有二级索引用于这些查询。

如果您想要更快的备份解决方案，可以采用以下解决方案：

如果您的所有表都是InnoDB，则可以使用--single-transaction选项，该选项使用事务隔离而不是锁定来确保一致的备份。然后3到6分钟之间的差异并不那么重要，因为其他客户端可以继续读取和写入数据库。（P.S。：无论如何你应该使用InnoDB。）
带有--tab选项的Mysqldump。这会将数据转储到制表符分隔的文件中，每个表一个文件。转储速度要快一点，但恢复速度要快得多。
Mydumper，mysqldump的开源替代品。这可以选择以多线程方式运行，并行备份表。有关简介，请参阅http://2bits.com/backup/fast-parallel-mysql-backups-and-imports-mydumper.html。
Percona XtraBackup执行物理备份，而不是像mysqldump或mydumper这样的逻辑备份。但它通常比进行逻辑备份更快。它还避免了锁定InnoDB表，因此您可以在客户端读写时运行备份。 Percona XtraBackup是免费的开源软件，它适用于普通的MySQL社区版，以及Percona Server，MariaDB甚至Drizzle等所有变种。 Percona XtraBackup针对InnoDB进行了优化，但它也适用于MyISAM和任何其他存储引擎（它必须在备份非InnoDB表时进行锁定）。

Answer 2

我的问题是：你真的需要转储还是副本？

有一种远离mysql转储的好方法，它使用Linux LVM“LVM Snapshot”：

http://www.lenzg.net/mylvmbackup/

想法是将数据库保持一毫秒，然后LVM将制作热拷贝（需要另一毫秒），然后数据库可以继续写入数据。 LVM副本现在可以用于您想要的每个操作：复制表文件或将其作为转储的新mysql实例打开（不在生产数据库上！）。

这需要对您的系统进行一些修改。也许那些mylvmbackup脚本没有完全完成jet。但如果你有时间，你可以在他们的基础上继续工作。

顺便说一句：如果你真的这么做，我对脚本非常感兴趣，因为我还需要一个快速的解决方案来将数据库从生产环境克隆到开发人员的测试系统。我们决定使用这个LVM快照功能，但是 - 一如既往 - 没时间开始使用它。

Mysqldump性能下降

2 个答案: