MySQL:无法创建/写入文件'/tmp/#sql_3c6_0.MYI'(错误代码:2) - 它甚至意味着什么？

Question

出于某种原因,我的生产DB决定吐出这条消息.所有应用程序调用都失败到DB并出现错误:

PreparedStatementCallback; SQL [ /*long sql statement here*/ ]; 
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2); 
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)

我不知道,这甚至意味着什么.没有文件#sql_3c6_0.MYI,由于某种原因/tmp我无法创建一个文件#.有没有人听说过或看到过这个错误？什么可能是错的,有些可能的事情要看？

MySQL DB似乎启动并运行,可以通过控制台查询,但应用程序似乎无法通过它.应用程序代码/文件没有变化.它只是发生了蓝色.所以我甚至不确定从哪里开始看,或者应用什么样的解决方案.有任何想法吗？

Answer 1

当我在Fedora系统上运行wordpress时,我也遇到了这个错误.

我用Google搜索,并找到解决此问题的方法.

也许这对你也有帮助.

1. 检查mysql配置:my.cnf

    cat /etc/my.cnf | grep tmpdir
   

   我看不到任何东西 my.cnf

2. 添加tmpdir=/tmp到my.cnf下[mysqld]

3. 重启web/app和mysql服务器

   /etc/init.d/mysqld restart

Answer 2

这通常意味着您的/tmp分区空间不足并且无法创建文件,或者mysqld由于权限问题导致进程无法写入该目录的任何原因.有时selinux你的游行下雨就是这种情况.

任何需要"临时文件"的操作都将/tmp默认进入该目录.你看到的名字只是一些内部随机名称.

Answer 3

在Fedora上使用systemd MySQL获取private/tmp目录.在/ proc/PID_of_MySQL/mountinfo中,您将找到如下行:

156 129 8:1/tmp/systemd-namespace-AN7vo9/private/tmp rw,relatime - ext4/dev/sda1 rw,seclabel,data = ordered

这意味着临时文件夹/ tmp/systemd-namespace-AN7vo9/private作为/ tmp安装在MySQL进程的私有命名空间中.不幸的是,如果不经常使用,tmpwatch会删除此文件夹.

我修改了/etc/cron.daily/tmpwatch并插入了这样的排除模式-X '/tmp/systemd-namespace*':

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/systemd-namespace*' \
        -X '/tmp/hsperfdata_*' 10d /tmp

副作用是不会自动删除未使用的私有命名空间文件夹.

Answer 4

文件名看起来像是MySQL中的查询创建的临时表.这些文件通常非常短暂,它们是在一个特定查询期间创建的,并在之后立即清理.

然而,它们可能变得非常大,具体取决于查询需要在临时表中处理的数据量.或者,您可能有多个并发查询创建临时表,如果有足够的这些查询同时运行,它们可能耗尽磁盘空间.

我做MySQL咨询,我帮助一个客户在他的根分区上出现间歇性磁盘完全错误,即使每次他看,他都有大约6GB的免费空间.在我们检查了他的查询日志之后,我们发现他有时会同时运行四个或更多查询,每个查询在/ tmp中创建一个1.5GB临时表,该表在他的根分区上.繁荣!

我给他的解决方案:

• 增加MySQL配置变量tmp_table_size,max_heap_table_size因此MySQL可以在内存中创建非常大的临时表.但是允许MySQL在内存中创建1.5GB临时表并不是一个好主意,因为没有办法限制同时创建多少个临时表.你可以通过这种方式快速耗尽记忆力.

• 将MySQL配置变量设置为tmpdir具有更多空间的另一个磁盘分区上的目录.

• 找出哪些查询正在创建如此大的临时表,并优化查询.例如,使用索引来帮助该查询将其扫描减少到表的较小片段.或者归档故事中的一些数据,以便查询没有那么多行要扫描.

Answer 5

非常感谢ArturZ指出我正确的方向.我没有在我的系统上安装tmpwatch,因此这不是我的问题的原因.但最终结果是一样的:systemd创建的private/tmp被删除了.这是发生的事情:

1. systemd通过带有CLONE_NEWNS标志的clone()创建一个新进程,以获取私有名称空间.或者它可能使用CLONE_NEWNS调用unshare().一样.

2. systemd在/ tmp中创建一个子目录(例如/ tmp/systemd-namespace-XRiWad/private)并将其安装在/ tmp上.因为CLONE_NEWNS在#1中设置,所以此挂载点对于所有其他进程是不可见的.

3. 然后systemd在这个私有命名空间中调用mysqld.

4. 某些特定的数据库操作(例如"describe;")创建和删除临时文件,这会产生更新/ tmp/systemd-namespace-XRiWad/private上的时间戳的副作用.其他数据库操作在不使用/ tmp的情况下执行.

5. 最终,即使数据库本身保持活动状态,也会在10天内继续运行,不会发生更新/ tmp/systemd-namespace-XRiWad/private上的时间戳的操作.

6. / bin/systemd-tmpfiles出现并删除了"old"/ tmp/systemd-namespace-XRiWad/private目录,有效地使private/tmp对mysqld不可用,而public/tmp仍可用于系统上的其他所有内容.

重新启动mysqld是有效的,因为这会在步骤#1重新启动所有内容,并使用全新的private/tmp目录.然而,问题最终又回来了.然后再次.

简单的解决方案是配置/ bin/systemd-tmpfiles,以便使用名称/ tmp/systemd-namespace-*保留/ tmp中的任何内容.我通过使用以下内容创建/etc/tmpfiles.d/privatetmp.conf来完成此操作:

x   /tmp/systemd-namespace-*
x   /tmp/systemd-namespace-*/private

问题解决了.

Answer 6

对我来说,这个问题是在长时间不使用mysql或网络服务器之后发生的.所以我确定我的设置在哪里正确; 只需重新启动服务即可修复此问题; 关于这个问题的奇怪部分是,仍然可以连接到数据库,甚至使用mysql工具查询/添加表.例如 :

mysql -u root -p

我重新开始使用:

systemctl start mysqld.service

或者服务mysqld restart或/etc/init.d/mysqld restart

注意:根据这些命令的机器/环境,应重启服务.

Answer 7

一种更好的方式对我有用.

    chown root:root /tmp
  chmod 1777 /tmp
  /etc/init.d/mysqld restart

这就对了.

请参见:http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html

http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/