我有一个RHEL 5系统，带有一个刚专用于MySQL服务器的全新硬盘。为了开始，我使用了" mysqldump --host otherhost -A | mysql"，即使我注意到联机帮助页也从未明确建议尝试这样做(将mysqldump放入文件是不可行的。我们正在谈论500G数据库)。

该过程以随机间隔失败，抱怨打开了太多文件(这时mysqld获取相关信号，并死亡并重新生成)。

我尝试在sysctl和ulimit上进行升级，但问题仍然存在。我该怎么办？

解决方案

回答

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

--lock-all-tables, -x

Lock all tables across all databases. This is achieved by acquiring a global read lock for the duration of the whole dump. This option automatically turns off --single-transaction and --lock-tables.

回答

据报道，对于较大的数据库(1、2、3)，mysqldump会产生该错误。 MySQL错误的解释和解决方法：

[3 Feb 2007 22:00] Sergei Golubchik
  This is not really a bug.
  
  mysqldump by default has --lock-tables enabled, which means it tries to lock all tables to
  be dumped before starting the dump. And doing LOCK TABLES t1, t2, ... for really big
  number of tables will inevitably exhaust all available file descriptors, as LOCK needs all
  tables to be opened.
  
  Workarounds: --skip-lock-tables will disable such a locking completely. Alternatively,
  --lock-all-tables will make mysqldump to use FLUSH TABLES WITH READ LOCK which locks all
  tables in all databases (without opening them). In this case mysqldump will automatically
  disable --lock-tables because it makes no sense when --lock-all-tables is used.

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

回答

如果数据库如此之大，那么我们将遇到一些问题。

• 我们必须锁定表以转储数据。
• mysqldump将花费非常长的时间，并且在此期间表将需要锁定。
• 在新服务器上导入数据也将花费很长时间。

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

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