同事连接数据库,查询数据报错了,Can't create/write to file '/tmp/#sql_89b_0.MYI' (Errcode: 177 - File exists):
而且我自己去连接,正常:
我让他关闭客户端连接,再重新执行查询语句,也是报一样的错误。
(1) 去mysql的error日志里面,没有看到异常信息;
(2) 在mysql的slow慢查询sql里面,也没有看到异常信息;
(3) Mysql所在的服务器的负载也不高,很低;
(4) Show full processlist; 也没有看到正在卡住的sql记录;
(5) show engine innodb status\G也没有看到死锁或者其他异常信息;
那么问题在哪里呢?去看下报错的原始文件吧
[root@zt_dbm1_13_11 ~]# ll /tmp/
total 4204
-rw-rw-r--. 1 zabbix zabbix 22 Aug 4 16:31 cu.txt
-rw-r--r--. 1 root root 1469 May 18 15:59 localhost-mysql_cacti_stats.txt:3317
-rw-rw-r--. 1 zabbix zabbix 4283869Aug 4 16:32 -mysql_cacti_stats.txt:3317
-rw-r--r-- 1 root root 101 Jul 28 15:06 percona-version-check
-rw-rw---- 1 mysql mysql 0 Aug 4 08:03 #sql_89b_0.MYD
-rw-rw---- 1 mysql mysql 1024 Aug 4 08:03 #sql_89b_0.MYI
[root@zt_dbm1_13_11 ~]#
看到时间是8月4日早上8点3分产生的临时文件,现在已经下午4点了,还存在没有释放,奇怪了,难道是当时一个复杂的慢查询导致的吗?或者是其它客户端的诡异问题?
解决办法:
尝试下移走这2个临时文件,应该就可以了。
[root@zt_dbm1_13_11 ~]# mv/tmp/#sql_89b_0.* /home/mysql/
[root@zt_dbm1_13_11 ~]#
然后让同事再查询,就ok了,他能正常执行查询sql语句了。
猜测是这样的,在早晨8:03分的时候,有个sql发起查询,然后消耗资源比较多,但是客户端突然因为每种原因死掉了,导致mysql执行查询生成的这个临时文件卡住了无法返回,然后就一直存在着。等下次去执行相同的记录,那么就会告知临时文件已经存在了,无法执行了。
而且也解释通了啥别人的电脑的客户端连接数据库没有报错,就那个同事的客户端连接报错的原因,是因为他的客户端分配的临时空间被占据了,而我mv移掉他以前占据的空间的时候,他重新执行查询就能顺利执行成功了。
|