我试图做一个Windows服务器上的mysqldump,我得到以下错误信息 :
mysqldump: Got error: 23: Out of resources when opening file '.\db\sometable.MYD' (Errcode: 24) when using LOCK TABLES
这是我正在运行的命令 :
mysqldump -u user -p"pass" --lock-tables --default-character-set=latin1 -e --quick databasename > "query.sql"
重新启动mysql服务没有帮助。
我总是得到同一个表的消息。
我已经尝试将table_cache和max_connectionsvariables分别从64减less到32和30到10,但是我仍然只是在这个时候得到一个不同的表的错误(从现在开始,错误消息总是提到第二个表)。
同样的脚本正在十几个其他Windows服务器上运行,并且没有问题。
所有数据库都有85个表格。
根据这里 – “操作系统错误代码24:太多打开的文件”,与更一般的错误23“资源不足”相对应。
所以看起来好像你用完了文件句柄。 这通常是服务器端设置/问题,无论是在MySQL中,还是在操作系统本身。
也许检查/调整MySQL本身的--open-files-limit
设置 ,看看是否有帮助。
此外,也许尝试运行转储,而没有其他人正在使用数据库,与--single-transaction
--Lock-File
--single-transaction
设置,而不是 – --Lock-File
,因为几个人build议这将一次工作,而不是全部打开它们一次(因此使用较less的文件句柄)。
除此之外,你可能不得不find一个根本原因,为什么这个特定的服务器耗尽资源。 这可能会涉及到通过禁用尽可能多的服务/进程进行故障排除,并查看转储是否通过。 然后从那里算出谁是罪魁祸首是吃了太多的资源,也许没有正确地解放他们。
你是否可以用--single-transaction
而不是--lock-tables
来试试它,例如表是InnoDB,而你没有使用Cluster表,并且ALTER TABLE,DROP TABLE,RENAME TABLE,TRUNCATE TABLE不会发生在转储期间? 最好确认你的MySQL支持组织是否可以,如果你有的话。
我只在unix上试过这个,但基本上如果我尝试使用一个有2000个表的数据库,它会失败,类似于你的错误,例如我已经使用了所有打开的文件句柄。
您可能会收到此错误:
在使用LOCK TABLES时,MySQL:Errcode:24
…升级到MySQL 5.5时出现其他错误,并在Plesk或任何其他执行mysqldump
操作系统上运行备份。
修理:
my.cnf
加:
open_files_limit=2048
重新启动MySQL
如果您收到:
无法从mysql.proc加载。 表格可能已损坏(1548)
这是升级到5.5的结果。 执行:
mysql_upgrade --force
testing并在CentOS 6.7和Plesk 12上工作。