什么是完成每日Mysql数据库备份的最佳方式，我们正在备份转储过程中有关键的MySQL数据库连接超时
我们使用dump和gzip
cron有一条线：
1 1 * * * root nice -n 19 /etc/automysqlbackup.sh 转储过程中出现问题。
逻辑备份（mysqldump，就像你的脚本所使用的）locking数据库。 这将破坏客户端操作。
我关于备份任务关键型数据库的方法是在OpenSolaris上使用InnoDB，并且每日对数据区和日志目录执行ZFS快照。
那些快照将被复制到离线服务器。
因为InnoDB是事务性的，而且快照是primefaces性的，所以在拍摄快照之前不需要closures服务器（从中恢复就像突然断电一样恢复：InnoDB支持它）。
正在倾销您的MySQL数据库在networking（NFS）共享？ 我们有一个类似的超时问题，所以我们不得不重新启动mysql守护进程，有以下两个选项：
/etc/my.cnf中
[mysqld] net_read_timeout=300 net_write_timeout=300
请让我们知道你的最新成果！
Stivi
如果您在LVM卷上运行MySQL数据文件，则可以创build快照。 看一下mylvmbackup是一个经过validation的解决scheme。
要创build一个实际使用mysql的转储，需要locking数据库以创build一致的转储文件。 我相信这是造成超时的原因。
我同意其他人的看法。 locking可能是导致超时的原因。 如果是这样的话，你可以创build一个mysql slave，然后进行转储（最好在单独的硬件上，但不pipe）。 这将防止你的主数据库在转储发生时被locking，一旦转储完成，从服务器将赶上主服务器。
我使用的方法（在FreeBSD上使用Postgres）是：
build立一个从服务器（你有一个，以防万一你的主数据库被点亮，对吧？）
确保从站上的数据目录在它自己的文件系统上（以后使用起来更容易！）
这对于MySQL来说是一样的。
如果您的服务器/ FS无法执行快照，请将第3步移至最后，然后省略第2步和第5步（复制在备份过程中停止，但确保备份一致，并且由于它是从属服务器，您的客户端不会甚至不知道它正在发生）。
如果你所有的表都是InnoDB，那么你可以通过–single-transaction来mysqldump。 这会将数据库转储为一致的状态，同时仍然允许其他更新发生在其他事务中。 我已经将一些系统迁移到了InnoDB，所以我可以拥有这个function。
如果你所有的表都是InnoDB，那么你可以使用–single-transaction。 这将仅仅简单地locking数据库，依靠事务中可用的内部一致性快照来完成备份。
如果他们不是，那么你将不得不做一些其他的事情; 如果你在Linux上，那么你可以使用LVM快照，只要你使用了LVM，而且你有一个空间（当你拍摄快照的时候，你仍然需要一个清空表格，但快照很快）。
如果您的底层存储设备（如RAID控制器）支持快照，您也可以使用其中一个。
你在使用InnoDB吗？ 如果是这样，看看Percona的xtrabackup工具。 或者更具体地说，使用其包装xtrabackup的innobackupex脚本，并增加了对其他任何MyISAM表的转储支持。
它可以在线备份（InnoDB的零locking），输出是一个有效的mysql数据目录，你可以复制到一个地方恢复通常恢复比恢复转储快得多。
它还支持将备份stream式传输到其他机器，增量备份，并且只是一个非常强大和有用的工具。
我使用它来备份500GB +范围内非常繁忙的数据库，即使在负载特别剧烈的情况下也不会有任何问题，复制延迟也非常小。
以下是一个示例使用情况，该备份使用备份，然后在备份中应用日志以使其可恢复：
innobackupex /var/backups/db innobackupex --apply-log --use-memory=1G /var/backups/db
在一个盒子上恢复这个备份会看起来像这样（mysql数据目录的path可能因发行版而异）：
cp -r /var/backups/db /var/lib/mysql/data chown -R mysql:mysql /var/lib/mysql/data
这个工具的Percona文档是相当不错的，所以你可以在这里阅读更多的信息：
http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
无论你走到哪里，一定要testing一下，包括恢复部分！