mysql - mysql转储 | 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

--锁定所有表，-x


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

Answer 2

据报道 mysqldump 会为较大的数据库（1、2、3）产生该错误。MySQL Bugs的解释和解决方法：

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

mysqldump 默认启用了 --lock-tables，这意味着它会在开始转储之前尝试锁定所有要转储的表。并且对非常多的表执行 LOCK TABLES t1, t2, ... 将不可避免地耗尽所有可用的文件描述符，因为 LOCK 需要打开所有表。

解决方法： --skip-lock-tables 将完全禁用此类锁定。或者， --lock-all-tables 将使 mysqldump 使用 FLUSH TABLES WITH READ LOCK 锁定所有数据库中的所有表（不打开它们）。在这种情况下，mysqldump 将自动禁用 --lock-tables，因为使用 --lock-all-tables 时没有任何意义。

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

Answer 3

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

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

2. mysqldump 将需要很长时间，在此期间您的表需要锁定。

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

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

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

Answer 4

我刚刚重新启动了“MySql”服务器，然后我就可以mysqldump完美地使用该命令了。

认为这可能是有用的提示。