从几天前开始,我们在安装 MySQL 时遇到了一些严重问题:MySQL 不断打开临时文件(正常行为),但这些文件从未释放。结果是,最终磁盘空间耗尽,我们必须重新启动服务并手动清理 /tmp。
使用 lsof,我们会看到类似这样的内容:
mysqld 16866 mysql 5u REG 8,3 0 692 /tmp/ibyWJylQ (deleted)
mysqld 16866 mysql 6u REG 8,3 0 707 /tmp/ibf5adsT (deleted)
mysqld 16866 mysql 7u REG 8,3 0 728 /tmp/ibGjPRyW (deleted)
mysqld 16866 mysql 8u REG 8,3 0 5678 /tmp/ibMQDLMZ (deleted)
mysqld 16866 mysql 13u REG 8,3 0 5679 /tmp/ibQAnM42 (deleted)
也许这没有关系,但是当我们关闭服务器时,文件最终被释放,我们可以在 MySQL 日志中看到以下警告:
121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1333 user: 'xxx'
121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1156 user: 'yyy'
121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1151 user: 'zzz'
其中 'xxx'、'yyy' 和 'zzz' 是不同的 mysql 用户(也是与数据库有活动连接的唯一 3 个用户)。
我们有几种理论:
操作系统中存在问题,导致文件处理程序保持打开状态。操作系统的“删除”操作是否会阻塞线程直到关闭?这也许可以解释关机时的警告以及进程终止时文件最终被删除的事实。
到目前为止,数据集非常小,因此临时文件相对较小,并且有足够的时间来释放文件句柄而不会耗尽磁盘空间。
我们在具有默认内核的 RHEL 6.2 上使用 Mysql 5.5。
答案1
嗯...这实际上不是一个解决方案,但我认为这是研究的结束。
这似乎是 MySQL 的一个错误。我们通过这个错误这似乎是这个
为了避免生成如此多的临时文件,我们将 binlog_cache_size 增加到了一个合理的值(在对应用程序进行了一些基准测试,并使用 lsof 检查了文件的大小之后)。如果您想了解更多信息,可以找到一篇有关解决此问题的其他选项的文章。
希望它能帮助到别人;)
答案2
作为参考,还有另一个非常类似的错误:http://bugs.mysql.com/bug.php?id=66237。而且这个问题在 5.5 中似乎还没有修复。