mysql flush logs-CSDN博客

本文链接：https://blog.csdn.net/guduwuzheguduwuzhe/article/details/84598259

文章详细介绍了在处理MySQL慢查询日志文件占用大量空间的问题时，如何避免Flush Logs操作导致的MySQL挂起。通过将日志文件重命名，然后再执行Flush Logs操作，可以有效解决问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最近遇到一台mysql机器，空间不足，查看后发现是slow log文件占了大量空间(ext4)，果断rm掉，然后再flush logs。flush logs的时候发现mysql会hang住。翻了一下flush logs的逻辑，执行flush logs的时候，mysql会执行reopen_file操作，reopen_file()先closeslow log file，再open，而这个过程是持有LOCK_log锁。目前mysql server层日志(slow/general/binary log)的写操作是都需要持有这个锁的。

这样，问题就来了。前面执行rm操作的时候，mysqld还在写对应的slow log，因此系统不会真正的删除这个文件，而执行flush logs操作的时候，mysql会去调用close()操作。close的manual是这么写的：

NAME
       close - close a file descriptor

DESCRIPTION
       close()  closes  a file descriptor, so that it no longer refers to any file and
       may be reused.  Any record locks (see fcntl(2)) held on the file it was associ-
       ated  with,  and  owned  by  the  process,  are removed (regardless of the file
       descriptor that was used to obtain the lock).

       If fd is the last copy of a particular file descriptor the resources associated
       with it are freed; if the descriptor was the last reference to a file which has
       been removed using unlink(2) the file is deleted.

linux删除文件的机制再加上mysql的LOCK_log这把大锁就会引起mysql hang住。类似的general log也会有这个问题。正确的做法是，将slow/general log mv成另外一个名字，再执行flush log操作，然后再去rm对应的文件。

链接：

http://www.mysqlperformanceblog.com/2007/12/09/be-careful-rotating-mysql-logs/

http://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents

http://digital-forensics.sans.org/blog/2011/03/28/digital-forensics-understanding-ext4-part-3-extent-trees

http://digital-forensics.sans.org/blog/2011/04/08/understanding-ext4-part-4-demolition-derby