mysqldump | MySQL产生“太多的打开文件”错误。为什么？

Question

我有一个 RHEL 5 系统，带有一个全新的硬盘驱动器，专门用于 MySQL 服务器。为了开始工作，我使用了“mysqldump --host otherhost -A | mysql”，尽管我注意到手册页从未明确建议尝试此操作（mysqldump 到文件中是不行的。我们谈论的是 500G 的数据库）。

这个过程会随机失败，抱怨打开的文件太多（此时 mysqld 收到相关信号，然后死掉并重生）。

我尝试在 sysctl 和 ulimit 上提高它，但问题仍然存在。我该怎么办？

Answer 1

默认情况下，mysqldump 对所有涉及的表执行每表锁定。如果您有很多表，可能会超过 mysql 服务器进程的文件描述符数量。尝试 --skip-lock-tables 或者如果锁定是必需的 --lock-all-tables。
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

--lock-all-tables, -x


锁定所有数据库中的所有表。这是通过在整个转储期间获取全局读锁来实现的。此选项自动关闭 --single-transaction 和 --lock-tables。

Answer 2

据报告 mysqldump 对于较大的数据库会产生该错误（1, 2, 3）。解释和解决方法来自 MySQL 错误:

2007年2月3日22:00] Sergei Golubchik这并不是真正的错误。

默认情况下，mySqlDump已启用 - 锁定式锁定桌，这意味着它试图在开始转储之前锁定所有表。并执行 LOCK TABLES t1, t2, ...对于真正的桌子，不可避免地会耗尽所有可用的文件描述符，因为锁需要打开的所有表。

解决方法：--skip-lock-tables 将完全禁用此类锁定。另外， - 锁定桌子将使mysqldump使用带有读取锁的冲洗表，该锁将所有数据库中的所有表锁定（无需打开它们）。在这种情况下，mysqldump将自动禁用 - 锁定桌子，因为当使用 - 锁定全桌子时，这是没有意义的。

编辑:请在下面的评论中查看 Dave 针对 InnoDB 的解决方法。

Answer 3

如果您的数据库那么大，您就会遇到一些问题。

1. 您必须锁定表才能转储数据。

2. mysqldump 将花费非常非常长的时间，在此期间您的表将需要锁定。

3. 在新服务器上导入数据也需要很长时间。

由于在 #1 和 #2 发生时您的数据库基本上无法使用，因此我实际上建议停止数据库并使用 rsync 将文件复制到其他服务器。它比使用 mysqldump 更快，并且比导入快得多，因为您没有额外的 IO 和 CPU 来生成索引。

在Linux的生产环境中，很多人将Mysql数据放在LVM分区上。然后，他们停止数据库，创建 LVM 快照，启动数据库，并在闲暇时复制已停止数据库的状态。