一个mysql /tmp目录爆满问题的处理
2017-06-18 12:19
621 查看
突然收到zabbix告警,说mysql服务器的/目录磁盘空间不足。
登录到服务器,看了下发现100GB的根目录,居然使用了差不多90GB。这台服务器上只跑了一个MySQL,应该不是日志未清理等其它原因造成的。
(说明:下面的几张截图是后期截的,当时已经有部分SQL跑完,释放掉部分磁盘空间了)
lsof |grep deleted 发现如下:
可以看到这个临时文件差不多有40GB。
show processlist; 如下:
上图看的话,没有涉及到写binlog的操作,但是由于单纯的select并不会造成/tmp目录爆满的情况,所以猜测他这个同一个事务里面之前还有涉及到写binlog的操作(update、delete等)。
官方的说明:
https://dev.mysql.com/doc/refman/5.6/en/binary-log.html
When a thread that handles the transaction starts, it allocates a buffer of
The
The
当事务开始时,它将缓冲区语句分配一个binlog_cache_size大小的缓冲区(我这里设置的是16777216bytes,即16MB)。 如果一个语句大于此,线程将打开一个临时文件来存储事务(默认是存放在/tmp/目录下)。 当线程结束时,临时文件会自动被删除。
上面就是因为事务里面的临时文件超过16MB了,被放到/tmp目录下了,但是这个临时文件实在太大了,导致磁盘空间不足告警了。
解决方法:
等上面的查询结束后,我们先关闭mysqld。(条件能允许的话,当然是让查询自己结束。如果直接kill掉的话,估计回滚也要话挺长时间的)
然后调整mysql的tmpdir到其他更大的磁盘去。
mkdir /bdata/mysql_tmp
chown mysql.mysql /bdata/mysql_tmp -R
chown 1777 -R /bdata/mysql_tmp -R
vim /etc/my.cnf
[mysqld]
tmpdir = /bdata/mysql_tmp
然后启动mysql即可
再次执行lsof|grep deleted 可以看到临时文件的路径已经改到了/bdata/mysql_tmp目录下了。
登录到服务器,看了下发现100GB的根目录,居然使用了差不多90GB。这台服务器上只跑了一个MySQL,应该不是日志未清理等其它原因造成的。
(说明:下面的几张截图是后期截的,当时已经有部分SQL跑完,释放掉部分磁盘空间了)
lsof |grep deleted 发现如下:
可以看到这个临时文件差不多有40GB。
show processlist; 如下:
上图看的话,没有涉及到写binlog的操作,但是由于单纯的select并不会造成/tmp目录爆满的情况,所以猜测他这个同一个事务里面之前还有涉及到写binlog的操作(update、delete等)。
官方的说明:
https://dev.mysql.com/doc/refman/5.6/en/binary-log.html
When a thread that handles the transaction starts, it allocates a buffer of
binlog_cache_sizeto buffer statements. If a statement is bigger than this, the thread opens a temporary file to store the transaction. The temporary file is deleted when the thread ends.
The
Binlog_cache_usestatus variable shows the number of transactions that used this buffer (and possibly a temporary file) for storing statements. The
Binlog_cache_disk_usestatus variable shows how many of those transactions actually had to use a temporary file. These two variables can be used for tuning
binlog_cache_sizeto a large enough value that avoids the use of temporary files.
The
max_binlog_cache_sizesystem variable (default 4GB, which is also the maximum) can be used to restrict the total size used to cache a multiple-statement transaction. If a transaction is larger than this many bytes, it fails and rolls back. The minimum value is 4096.If you are using the binary log and row based logging, concurrent inserts are converted to normal inserts for
CREATE ... SELECTor
INSERT ... SELECTstatements. This is done to ensure that you can re-create an exact copy of your tables by applying the log during a backup operation. If you are using statement-based logging, the original statement is written to the log.
当事务开始时,它将缓冲区语句分配一个binlog_cache_size大小的缓冲区(我这里设置的是16777216bytes,即16MB)。 如果一个语句大于此,线程将打开一个临时文件来存储事务(默认是存放在/tmp/目录下)。 当线程结束时,临时文件会自动被删除。
上面就是因为事务里面的临时文件超过16MB了,被放到/tmp目录下了,但是这个临时文件实在太大了,导致磁盘空间不足告警了。
解决方法:
等上面的查询结束后,我们先关闭mysqld。(条件能允许的话,当然是让查询自己结束。如果直接kill掉的话,估计回滚也要话挺长时间的)
然后调整mysql的tmpdir到其他更大的磁盘去。
mkdir /bdata/mysql_tmp
chown mysql.mysql /bdata/mysql_tmp -R
chown 1777 -R /bdata/mysql_tmp -R
vim /etc/my.cnf
[mysqld]
tmpdir = /bdata/mysql_tmp
然后启动mysql即可
再次执行lsof|grep deleted 可以看到临时文件的路径已经改到了/bdata/mysql_tmp目录下了。
相关文章推荐
- mysql Got error 28 from storage engine错误,Mysql导致tmp目录空间耗尽问题
- mysql误操作后通过binlog恢复,同时解决tmp目录满的问题
- mysql Got error 28 from storage engine错误,Mysql导致tmp目录空间耗尽问题
- 二、处理MVC多级目录问题——以ABP为基础架构的一个中等规模的OA开发日志
- (求助)一个关于ACCESS数据库转化到MYSQL后的处理问题
- 最近遇到一个问题SQLSERVER2005 目录名称无效(批处理过程出错,不能查询)
- Mysql导致tmp目录空间耗尽问题(ERROR 1030 (HY000): Got error 28 from storage engine)
- MySQL 如何在一个语句中更新一个数值后返回该值 -- 自增长种子竞态问题处理
- Asp.net中处理一个站点不同Web应用共享Session的问题
- D3D中一个明暗处理的问题(D3DSHADE_FLAT) (问题,希望DX解答)
- 处理一个电脑启动问题
- 提一个比较不知道如何处理的问题?
- java 与 mysql 中文问题的处理
- 前台一个日期处理问题
- Asp.net中处理一个站点不同Web应用共享Session的问题
- 正确使用mysql + MFC的一个要注意问题
- 处理一个傻子引发得问题
- Java 与 mysql 中文问题的处理
- 一个mysql表索引被破坏的问题及解决
- 从一个网页传送表单到别一个网页时的中文处理问题