mysql如何配置日志保留天数_mysql expire_logs_days设置

MySQL Binlog保留天数配置：从参数废弃到生产环境兜底方案

expire_logs_days 设置后不生效？先确认 MySQL 版本和启动方式

配置后没有效果？问题很可能出在版本上。从 MySQL 5.7.6 版本开始，expire_logs_days 参数已被官方标记为“废弃”，取而代之的是更精确的 binlog_expire_logs_seconds 参数。如果你正在使用 MySQL 8.0 或更高版本，却仍在配置 expire_logs_days，那么它将完全失效。

需要明确的是，这个参数家族（无论是按天还是按秒）仅管理**二进制日志**，即 binlog。错误日志、慢查询日志等有各自的清理机制，不能依赖此参数进行管理。

• 第一步，确认当前设置：执行 SHOW VARIABLES LIKE 'expire_logs_days'; 或 SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; 来查看当前值。
• 动态设置的局限性：即使使用 SET GLOBAL 命令成功修改了参数（需要 SUPER 权限），它也只会影响此后新生成的 binlog 文件。已经存在的旧日志文件会保留，直到下次清理任务被触发。
• 注意配置被覆盖：如果 MySQL 服务通过 systemd 管理，仅在配置文件 my.cnf 中修改是不够的，必须重启服务才能使配置持久化。否则，通过 SET GLOBAL 所做的临时调整会在服务重启后丢失。

如何安全设置 binlog 保留 7 天？推荐使用 binlog_expire_logs_seconds

既然按天控制的参数已过时，建议采用更精确的秒级参数进行管理。设置保留7天很简单：7 天 × 24 小时 × 3600 秒 = 604800 秒。相比过去“天”的粗粒度，秒级参数在 MySQL 5.7.6 及以上版本不仅默认启用，而且优先级更高。

具体操作，建议遵循“持久化配置 + 运行时生效”的双重策略：

• 持久化配置：在 my.cnf 配置文件的 [mysqld] 段落中，明确添加：
  binlog_expire_logs_seconds = 604800
• 运行时生效：连接到数据库，执行 SET GLOBAL binlog_expire_logs_seconds = 604800; 使设置立即生效，无需重启服务。
• 可选立即清理：如果希望立刻清理7天前的日志，可以执行：
  PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

执行 PURGE 命令前需注意：如果数据库存在主从复制架构，请确保从库已经完成同步，否则此命令可能会中断复制链路。

为什么 PURGE 后磁盘空间没有立刻释放？

一个常见的运维困惑是：执行了清理命令后，使用 du -sh /var/lib/mysql 查看，磁盘空间为何没有变化？这通常不是命令失效，而是操作系统层面的机制。MySQL 删除的是文件在系统目录中的引用（句柄），但如果还有进程（例如 mysqld 自身，或正在运行的备份脚本、监控工具）正打开着这个文件，那么它占用的磁盘空间就不会被立即回收。

• 排查文件占用：可以运行 lsof -p $(pgrep mysqld) | grep -i binlog 命令，查看是否有进程仍持有旧的 binlog 文件。
• 彻底释放空间的方法：最直接的方法是在业务低峰期重启 mysqld 服务，这会强制关闭所有文件句柄，让操作系统回收空间。
• 日常优化建议：可以考虑设置 sync_binlog = 1 和 binlog_format = ROW。前者使每次事务提交都同步写入日志，后者使日志记录更紧凑，两者结合有助于控制单个 binlog 文件的大小，减轻后续清理的压力。

线上环境切勿仅依赖 expire 参数自动清理

在生产环境中，将日志清理完全交给自动参数存在风险。MySQL 的自动清理机制并非定时触发，它只在几个特定时机工作：例如 binlog 文件切换时、执行 FLUSH LOGS 命令时，或后台线程的定期扫描周期到达时。这意味着，对于一个写入流量很低的数据库实例，可能连续多日都不会切换 binlog，导致本应被清理的过期文件持续堆积在磁盘上。

因此，可靠的方案必须增加一层“兜底”机制：

• 增加定时任务：通过 crontab 设置每日任务，例如在凌晨执行：mysql -e “PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);”，进行强制清理。
• 设置监控告警：定期检查 SHOW BINARY LOGS; 的输出，关注日志文件数量和其中最老文件的时间。一旦发现存在超过10天的日志，就触发告警。
• 注意权限配置：执行清理命令的账号需要具备足够权限，通常是 REPLICATION CLIENT 和 SUPER（在 MySQL 8.0+ 中，后者可能被 SYSTEM_VARIABLES_ADMIN 等更细粒度的权限替代）。

总而言之，自动参数只是一个辅助工具。在追求稳定性的生产环境中，定期的检查与必要的人工干预，才是防止 binlog 日志在短期内占满磁盘空间的关键保障。