在my.cnf中忽略了expire_logs_days

Cod*_*y S 12 mysql database-replication

我有一对为主从复制设置的MySQL数据库.奴隶做得很好.

另一方面,尽管我做了最好的(自动化)努力,但主人仍在囤积二进制日志.

我正在尝试在MySQL的my.cnf文件中设置'expire_logs_days'变量,但由于某种原因它似乎被忽略了.我的my.cnf文件看起来像:

[mysqld]
...
log-bin=/var/log/mysql/mysql-bin.log
server-id=1
expire_logs_days=3
log_bin_trust_function_creators=TRUE
sync_binlog=1

[mysqld_safe]
...
Run Code Online (Sandbox Code Playgroud)

但是当我SHOW VARIABLES WHERE Variable_Name='expire_logs_days'在MySQL中运行时,它会返回一个值0

我试过了:

  • 重启MySQL
  • 使用此行: expire_logs_days='3'
  • 检查其他my.cnf文件:
    • mysqld --help --verbose | grep cnf
    • 找到了这条线: /etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf order of preference
    • 我的my.cnf档案位于/etc/my.cnf
    • 在其他位置没有名为my.cnf的文件
  • SET GLOBAL expire_logs_days=3 在MySQL中工作,但本身并没有真正解决我的问题

这就是我能想到的所有事情.我已经运行了手动PURGE命令,它运行得很好,但是我更喜欢(尽管如果没有办法,我还是会这样做)不使用cron运行PURGE命令.

有人有什么想法吗?我只是轻拍.

谢谢.

Rol*_*DBA 11

你问题的事实

  • 二进制日志无法旋出
  • 你说你可以运行PURGE BINARY LOGS

这是我的工作理论

由于您可以使用删除二进制日志PURGE BINARY LOGS;,因此我有两个地方供您查看,但您没有提及

地点#1: mysql-bin.index

此文件包含所有二进制日志的位置.设置expire_logs_days时,mysqld将打开此文本文件,检查每个文件中的日期时间戳,直到遇到时间戳小于的二进制日志NOW() - INTERVAL expire_logs_days DAY).

mysql-bin.index中的二进制日志预计在数字上是连续的.如果二进制日志不是数字连续的,则禁用日志轮换.

PLACE#2:/var/log/mysql文件夹

根据您的说明my.cnf,此文件夹包含所有二进制日志.

这是两个问题:

  1. 是否存在/var/log/mysql数字连续的二进制日志?
  2. 是否有任何二进制日志/var/log/mysqlNOT IN mysql-bin.index

为什么这些情况会出现?

有时,人们会删除操作系统中的二进制日志.这可以抛弃mysqld,因为mysqld用于mysql-bin.index内部跟踪二进制日志的存在.简单地删除二进制日志,rm -f逻辑上破坏日志轮换机制,因为mysqld知道它.

建议

如果是其中之一或两者,您可以按如下方式清除它:

mysql -ANe"RESET MASTER"
service mysql stop
cd /var/log/mysql
rm -f mysql-bin.*
cd
service mysql start
Run Code Online (Sandbox Code Playgroud)

在此之后,你应该有一个品牌打屁股新的二进制日志设置.

试试看 !!!