MySQL 数据库备份：性能问题答案

【问题标题】：MySQL database backup: performance issuesMySQL 数据库备份：性能问题
【发布时间】：2011-10-04 16:18:57
【问题描述】：

伙计们，

我正在尝试为一个同时具有 InnoDB 和 MyISAM 表的大型生产数据库（半个 gig）设置定期备份。到目前为止，我一直在使用 mysqldump，但我发现它花费的时间越来越长，并且在 mysqldump 运行时服务器完全没有响应。

我想征求你的意见：我该怎么做

使 mysqldump 备份非阻塞 - 为进程分配低优先级或类似的东西，或者
找到另一种更好/更快/无阻塞的备份机制。

我知道 MySQL 企业备份产品 (http://www.mysql.com/products/enterprise/backup.html) 的存在 - 它很贵，这不是这个项目的选择。

我已经阅读了有关将第二台服务器设置为“复制从属”的信息，但这对我来说也不是一个选择（这需要硬件，这需要花费 $$）。

谢谢！

更新：关于我的环境的更多信息：Ubuntu、最新的 LAMPP、Amazon EC2。

【问题讨论】：

刚刚发现一个很相似的问题：stackoverflow.com/questions/65093/…

标签： mysql performance backup mysqldump database-backups

【解决方案1】：

如果无法复制到从属设备，您可以利用文件系统，具体取决于您使用的操作系统，

我在一个相当大的 MySQL 数据库 (30GB+) 上使用 ZFS 快照作为备份方法，它可以很快完成（从不超过几分钟）并且不会阻塞。然后，您可以将快照挂载到其他位置并将其备份到磁带等。

【讨论】：

@Mechanical snail：不，我在 Solaris 上使用 ZFS。
谢谢！看起来是最突出的建议。不过，我希望有工具可以加快此设置的速度..
@RichAdams：感谢您的回答！不幸的是，第三个链接不再起作用了。

【解决方案2】：

编辑：（之前的回答是建议从备用数据库备份，然后我注意到亚历克斯在他的问题中排除了这一点。）

假设硬件可以跟上，您的复制从属服务器没有理由不能在相同的硬件上运行。获取源代码压缩包./configure --prefix=/dbslave; make; make install;，您将拥有第二个完全位于 /dbslave 下的 mysql 服务器。

EDIT2：复制还有很多其他好处。例如，在运行复制的情况下，您可能能够恢复 binlog 并在上次备份的顶部重放它，以在某些类型的灾难后恢复额外的数据。

EDIT3：您提到您在 EC2 上运行。另一个降低成本的有点人为的想法是尝试设置另一个具有 EBS 卷的实例。然后使用 AWS api 启动该实例足够长的时间，以使其赶上二进制日志中的写入，转储/压缩/发送快照，然后将其关闭。不是免费的，而且设置起来很费力，但比 24x7 运行实例要便宜得多。

【讨论】：

感谢您的建议，但是-1。直接引用问题：“我已经读过关于将第二台服务器设置为“复制从属”的信息，但这对我来说也不是一个选择（这需要硬件，这需要花费 $$）。”
我注意到我一完成我的答案，并对其进行了编辑。公平地说，我在最初的回答中没有提到第二台机器;-)
收回我的 -1。有趣的想法。我担心在单个盒子上设置它的性能影响 - 我猜这种方法会使 mysqlserver 写入性能减慢一半以上（第二个实例，传输开销）。你怎么看？我在 EC2 标准实例上运行。
额外负载量取决于您的应用程序的写入量。每个应用程序都不一样，所以我不能在那里给你确切的指导。

【解决方案3】：

尝试 maatkit (http://www.maatkit.org/) 中的 mk-parallel-dump 实用程序

问候，

【讨论】：

mk-parallel-dump 已被 Percona 弃用。它仍然有效，但 Percona 不再支持将其用于生产用途。事实上，这个 URL 明确声明不要使用 mk-parallel-dump 作为备份程序：maatkit.org/doc/mk-parallel-dump.html

【解决方案4】：

您可能会考虑通过一种称为“日志传送”的方法在此处使用二进制日志。就在每次备份之前，发出一个命令来刷新二进制日志，然后您可以通过常规文件系统操作复制除当前二进制日志之外的所有内容。

这种方法的优点是您根本不会锁定数据库，因为当它按顺序打开下一个二进制日志时，它会释放先前日志上的所有文件锁定，因此不会影响处理。 Tar'em，zip'em 就位，随心所欲，然后将其作为一个文件复制到备份系统中。

使用二进制日志的另一个优点是，如果日志可用，您最多可以恢复 X 个时间点。 IE。您有去年的完整备份，以及从那时到现在的所有日志。但是您想查看 2011 年 1 月 1 日的数据库。您可以发出“直到 2011 年 1 月 1 日”的恢复，当它停止时，就数据库而言，您在 2011 年 1 月 1 日。

我不得不用它一次来扭转黑客造成的破坏。

绝对值得一试。

请注意...二进制日志通常用于复制。没有什么说你必须这样做。

【讨论】：

【解决方案5】：

除了 Rich Adams 和 timdev 已经建议的内容之外，编写一个在低使用率期间触发的 cron 作业，以按照建议执行从属任务以避免高 CPU利用率。

也检查mysql-parallel-dump。

【讨论】：