怎样配置MySQL的binlog自动过期清理与保留策略-mysql教程-PHP中文网

mysql 8.0+ 必须设 binlog_expire_logs_seconds（如604800秒）并启用 binlog_expire_logs_auto_purge=on 才能自动清理，expire_logs_days 已废弃；设错版本、不重启、不触发 flush logs 或从库依赖未满足均会导致清理失效。

怎样配置mysql的binlog自动过期清理与保留策略

必须设，不设磁盘迟早被撑爆；但设了不生效、设错版本、设完不重启、设了却删不掉——这四类问题占了线上 binlog 清理失败的 90% 以上。

确认 MySQL 版本再选参数：5.7 和 8.0+ 完全不同

MySQL 5.7 只认 expire_logs_days，单位是“天”；MySQL 8.0.28+ 才真正支持 binlog_expire_logs_seconds（单位秒），且它优先级更高。旧版本设了也白设。

先查版本：SELECT VERSION();，别只看文档写法。比如你用的是 8.0.26，那 binlog_expire_logs_seconds 就无效，仍得靠 expire_logs_days。

常见错误：

在 5.7 上写 binlog_expire_logs_seconds = 604800，配置文件里加了也没用
在 8.0.28+ 上同时写 expire_logs_days = 7 和 binlog_expire_logs_seconds = 604800，后者生效但 MySQL 会报警告
误以为 SET GLOBAL binlog_expire_logs_seconds = ... 重启后还有效——它不持久，必须写进配置文件或用 SET PERSIST

配置写对 + 服务重启 + 最老 binlog 真超期 + 从库不依赖 = 四个条件缺一不可

自动清理不是“设完就跑”，而是满足全部四个条件才真正触发删除。少一个，SHOW BINARY LOGS 里就还堆着一堆“该删没删”的文件。

验证是否真生效：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

查变量：SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; 或 SHOW VARIABLES LIKE 'expire_logs_days';，返回值不是 0 才算启用
查最老 binlog 时间：SHOW BINARY LOGS; 看第一个文件的 File_size 列没用，要看它的操作系统 mtime（用 ls -lt /var/lib/mysql/mysql-bin.* 确认）
查从库依赖：SHOW SLAVE STATUS\G 看 Relay_Master_Log_File 是否还在 SHOW BINARY LOGS 列表里，且不是第一个
检查 binlog_expire_logs_auto_purge 是否为 ON（MySQL 8.0.29+ 新增开关，优先级最高，设成 OFF 就彻底禁用清理）

为什么 flush logs 后 binlog 还不删？清理时机不是实时的

MySQL 不是每小时扫一遍磁盘删文件，而是只在三个时刻检查并清理：MySQL 启动时、执行 FLUSH LOGS 时、或 binlog 文件大小达到 max_binlog_size 触发切换时。没有这些动作，哪怕过期一周也不会动。

所以在线调参后，必须手动触发一次清理：

先 SET GLOBAL expire_logs_days = 7; 或 SET GLOBAL binlog_expire_logs_seconds = 604800;
再立刻执行 FLUSH LOGS;（注意：需要 RELOAD 权限）
观察 SHOW BINARY LOGS;，最老的文件序号应跳变，超期文件消失

如果 FLUSH LOGS 后仍不删，大概率是：最老那个 binlog 文件还没超期（mtime 比设定时间新），或者从库还在读它。