MySQL 8.0 binlog默认永不清除,必须配置binlog_expire_logs_seconds(如604800)并设auto_purge=ON才自动清理,expire_logs_days已废弃且设则报错3683;需先查log_bin、过期秒数及auto_purge状态,再手动PURGE前核对从库Relay_Master_Log_File安全下限,最后执行FLUSH LOGS释放句柄。

MySQL 8.0 的 binlog 默认永不清除,不配 binlog_expire_logs_seconds 就一定会撑爆磁盘。 它不是“可能”或“偶尔”,而是只要 log_bin 开着、又没设过期秒数,日志就只增不减——哪怕你只跑一个 INSERT,一年后也能攒出几百 GB。
确认当前配置是否生效(别猜,直接查)
很多问题根本不是配置错了,而是压根没生效。先连上 MySQL 执行三句检查:
-
SHOW VARIABLES LIKE 'log_bin';—— 必须返回ON,否则后面全白搭 -
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';—— 若是0或NULL,说明自动清理完全关闭 -
SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge';—— 必须是ON,设了秒数但它是OFF就等于关掉了总闸
注意:expire_logs_days 在 8.0.11+ 已废弃,查出来有值也代表不了什么,甚至可能和 binlog_expire_logs_seconds 冲突报错 [3683]。
永久设置 binlog_expire_logs_seconds(重启才生效)
临时 SET 只活到下次重启,生产环境必须写进配置文件。宝塔用户路径通常是 /www/server/mysql/etc/my.cnf,非宝塔常见为 /etc/my.cnf 或 /etc/mysql/my.cnf:
- 在
[mysqld]段末尾加两行:binlog_expire_logs_seconds = 604800binlog_expire_logs_auto_purge = ON - 如果之前设过
expire_logs_days,顺手清掉:SET GLOBAL expire_logs_days = 0;,避免冲突 - 保存后必须重启:
systemctl restart mysqld(宝塔面板点“重启”也行) - 重启完立刻再查一遍
binlog_expire_logs_seconds,确保值已更新
7 天 = 604800 秒,3 天 = 259200 秒,按业务 RPO 自行取舍;低于 86400(1 天)要谨慎,主从延迟大时容易误删。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
手动清理堆积的旧 binlog(配置不管“过去”,只管“未来”)
设好参数后,已存在的几百个 mysql-bin.000xxx 不会自动消失。磁盘告急时得手动 PURGE,但错删一条就会断主从:
- 主库执行:
SHOW MASTER STATUS;记下当前File(比如mysql-bin.000150) - 每台从库执行:
SHOW SLAVE STATUS\G,盯住Relay_Master_Log_File(比如从库 A 是mysql-bin.000132,B 是mysql-bin.000128) - 取所有从库中序号最小的那个(这里是
000128),安全下限就是TO 'mysql-bin.000129' - 主库执行:
PURGE BINARY LOGS TO 'mysql-bin.000129';(注意:不删.000129本身) - 执行后若
df -h看空间没释放,大概率是句柄还被 mysqld 占着,补一句FLUSH LOGS;强制轮转即可
绝对不要用 RESET MASTER,它会重置序列号,所有从库立即复制失败;也别用 rm mysql-bin.*,会破坏 binlog.index 导致后续自动清理失效。
为什么 FLUSH LOGS 有时比等自动清理更关键
binlog_expire_logs_seconds 不是定时任务,它只在三个时机触发检查:MySQL 启动、FLUSH LOGS、或当前 binlog 写满(达到 max_binlog_size)。也就是说,即使你设了 7 天,若当前 mysql-bin.000150 还没写满、也没重启、也没人执行 FLUSH,那过期文件就一直挂着不删。
所以配置改完后,建议立刻执行一次:FLUSH LOGS;。它会生成新文件(如 mysql-bin.000151),同时触发对旧文件的过期扫描——这才是真正释放空间的最快路径。










