我正在使用 5.7.37-log MySQL Community Server。我的 mysqld.cnf 如下所示:
server_id = 11
log_bin = bin.log
log-bin-index = bin-log.index
binlog_format = row
max_binlog_size = 100M
socket = mysql.sock
expire_logs_days = 1
我对 expire_logs_days = 1 的期望是 1 天后日志将被清除。而且我将无法看到较旧的日志.. 但是当我在一周后检查日志时,当当前日志名称为 bin.000006 时,我仍然可以看到 bin.000001。当我重新启动 mysql 服务器并创建新日志时,我观察到旧日志被清除。
但我不想重新启动服务器来删除我的旧文件。它们应该被自动删除。我担心在累积旧日志时会填满磁盘空间(我肯定不需要它们)并且我不想为此重新启动 sql server。
我也曾在某些表格中看到建议运行PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY;
但是我不明白当我们已经设置配置时手动运行上面的语句有什么意义。
如果我的理解和期望是否正确,请帮助我。以及如何测试或确保日志被自动删除?并且对磁盘空间无害。
附上我生成的 bin 日志的屏幕截图。
这是您必须了解的有关二进制日志过期的事情
回到 2017 年 7 月 13 日,我回答了MySQL Still purging binary logs and ignoring expire_logs_days。我已经提到过 MySQL 5.0.x 是如何删除二进制日志直到午夜的。
从那时起,expire_logs_days在 5.7 中以秒为粒度运行。
现在,MySQL 8.0 有更多变量来微调二进制日志清除
但是,还有一点您必须意识到
binlog.00006
有时间戳Apr 25 09:12
binlog.00003
有时间戳Apr 24 16:08
那为什么
binlog.00003
还没有消失???24 小时前
Apr 25 09:12
(binlog.00006
时间戳)是Apr 24 09:12
。如果 的 UNIX 时间戳Apr 24 09:12
嵌入在 中binlog.00003
,则该二进制日志必须保留在原地。一旦达到 的
binlog.00006
UNIX 时间戳Apr 25 16:08
,下次 mysqld 轮换从到或如果您手动执行at时,thenbinlog.00003
将消失。binlog.00006
binlog.00007
FLUSH BINARY LOGS;
Apr 25 16:09
如果您想查看里面的 UNIX 时间戳,
binlog.00003
只需运行并查看时间戳(UNIX 时间戳值和人类可读)
关于 binlog 过期的一件棘手的事情你必须记住,它不会发生,直到 MySQL 服务器打开一个新的 binlog 文件。因此,只要它当前正在写入
bin.000006
,最旧的文件就不会过期。当它滚动到 时bin.000007
,MySQL 服务器会检查哪些(如果有的话)较旧的 binlog 文件需要过期。所以从理论上讲,如果您的写入速度
bin.000006
足够慢,则需要很多天才能填满并滚动到bin.000007
,因此您的旧二进制日志文件会挂起很多天。您不必重新启动 MySQL 服务器来强制它打开一个新的二进制日志,也不必等到二进制日志文件填满其最大大小。您可以
FLUSH LOGS;
随时运行。这将关闭打开的日志文件,包括二进制日志,然后再次打开它们。对于二进制日志,它还会打开一个新文件,即使最后一个文件还未满。也有可能你一天写了一大波,很多新的 binlog 文件被快速打开和填充,但最旧的 binlog 文件还不到 1 天,所以它没有过期。因此,您仍然可以在旧文件过期之前填满磁盘空间。
MySQL 缺少的是基于二进制日志总空间的过期,而不是基于时间的过期。
Percona Server 是 MySQL 的一个分支。在 8.0 版本中,他们引入了一个选项
binlog_space_limit
,该选项为二进制日志使用的总存储设置了绝对上限。看: