如何配置自动清除过期Binlog_expire_logs_days与保留策略

MySQL 5.7+ 应使用 binlog_expire_logs_seconds（单位秒，正整数）替代已废弃的 expire_logs_days；设为 0 禁用自动清理，默认 2592000（30 天）；需 SET PERSIST 持久化，且仅对未被复制线程或远程读取引用的 binlog 生效。

MySQL 5.7+ 怎么设置 binlog_expire_logs_seconds 替代已废弃的 expire_logs_days

MySQL 8.0.11 起，expire_logs_days 已被标记为废弃；5.7 虽还能用，但行为不一致（比如不作用于 GTID 模式下部分 binlog）。真正生效且推荐的配置是 binlog_expire_logs_seconds，单位是秒，精度更高。

常见错误现象：改了 expire_logs_days = 7，发现 binlog 还在涨，SHOW BINARY LOGS 里老文件没删——大概率是启用了 GTID 或版本 ≥8.0.11，旧参数直接被忽略。

• binlog_expire_logs_seconds 必须是正整数，设为 0 表示禁用自动清理（危险，慎用）
• 默认值是 2592000（30 天），不是 0，也不是“不限制”
• 修改后需执行 SET PERSIST binlog_expire_logs_seconds = 604800（保留 7 天）才持久化，仅 SET GLOBAL 重启即失效
• 该参数只控制“未被任何复制线程（包括从库 IO 线程、本地 mysqlbinlog --read-from-remote-server）引用”的 binlog 文件

为什么 PURGE BINARY LOGS 手动清理有时不生效

手动执行 PURGE BINARY LOGS TO 'mysql-bin.000123' 或 PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00' 失败，多数不是语法问题，而是权限或状态卡住。

典型报错：ERROR 1377 (HY000): Failed to purge old binary logs，背后原因往往藏在 SHOW SLAVE STATUSG 或 SELECT * FROM performance_schema.replication_applier_status_by_coordinator 里。

• 从库 IO 线程还在拉取某个 binlog 文件（Master_Log_File 指向它），主库就不能删
• 启用 log_slave_updates 的级联从库，自己也生成 binlog，它的 Relay_Master_Log_File 若指向某文件，上游主库也不能删
• 使用 mysqlbinlog --read-from-remote-server 连接中，会临时持有 binlog 文件句柄，导致 PURGE 阻塞
• 执行前先查 SHOW BINARY LOGS 和 SHOW MASTER STATUS，确认目标文件确实不在 File 列表最前面（即非当前活跃日志）

保留策略怎么兼顾备份窗口与磁盘压力

单纯按天数保留（如 7 天）容易出问题：如果某天业务峰值打满磁盘，binlog 写入量暴增，7 天可能占掉 200GB；而低峰期每天才 200MB，留 30 天也才 6GB。硬编码天数不灵活。

更稳妥的做法是「双保险」：用 binlog_expire_logs_seconds 设基础保留期，再配合定时脚本做空间兜底。

• 先设 binlog_expire_logs_seconds = 604800（7 天）保底线，防无限堆积
• 写个简单 shell 脚本，每天检查 du -sh /var/lib/mysql/mysql-bin.* | sort -hr | head -20，若总大小超 100GB，就调用 PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY)
• 注意：脚本里不要用 rm -f 直删文件，必须走 PURGE 命令，否则 index 文件不同步，MySQL 启动会报错
• Percona Toolkit 的 pt-find 不适用于 binlog 清理，它绕过 MySQL 内部状态，风险极高

GTID 模式下清理 binlog 的隐藏约束

开启 gtid_mode = ON 后，MySQL 会严格校验 binlog 是否被所有从库消费完毕。哪怕只有一个从库网络断开几小时，对应 binlog 就一直卡着不删——这是设计使然，不是 bug。

现象：binlog_expire_logs_seconds 设了 1 天，但 SHOW BINARY LOGS 显示还有 5 天前的文件，SELECT @@global.gtid_executed 和从库的 Retrieved_Gtid_Set 对不上。

• 必须确保所有从库的 Retrieved_Gtid_Set 包含主库 gtid_purged 的前缀，否则主库不敢删
• 临时解法（慎用）：在从库执行 STOP SLAVE; RESET SLAVE ALL;，再重新 CHANGE MASTER，但这会丢失复制位点
• 长期建议：监控 Seconds_Behind_Master + Retrieved_Gtid_Set 差值，告警早于磁盘爆满 24 小时
• 不要试图用 SET GLOBAL gtid_purged = '……' 强制覆盖，除非你清楚每条事务的因果链

真正麻烦的从来不是配哪个参数，而是搞清“谁还在读这个文件”。磁盘报警时翻日志，八成问题出在某个失联但从库的 Master_Host 配置还活着。