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 STATUS\G 或 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 配置还活着。
