MySQL 8.0+ 必须使用 binlog_expire_logs_seconds（如604800秒），expire_logs_days 已废弃且设则报错3683；手动清理前须核对主从最旧未读日志，PURGE 后空间未释放需 FLUSH 或重启释放句柄。
MySQL 8.0+ 不能设 expire_logs_days，否则报错 3683
直接在 MySQL 8.0.11 及以上版本执行 SET GLOBAL expire_logs_days = 7; 会触发错误：[3683] The option expire_logs_days and binlog_expire_logs_seconds cannot be used together。这不是配置顺序问题，而是该参数已被官方标记为 deprecated，即使写进配置文件也**不生效或行为不可靠**。
必须改用秒级参数：binlog_expire_logs_seconds。例如 7 天对应 604800 秒：
- 临时生效（重启丢失）：
SET GLOBAL binlog_expire_logs_seconds = 604800; - 永久生效：编辑
/www/server/mysql/etc/my.cnf（宝塔路径），在[mysqld]段末尾添加：binlog_expire_logs_seconds = 604800 - 若之前设过
expire_logs_days，先清零避免冲突：SET GLOBAL expire_logs_days = 0;
手动 PURGE BINARY LOGS 前必须核对主从状态
自动策略只管“未来”，已堆积的 binlog 不会自动删。磁盘告急时得手动清理，但误删会导致主从断裂——PURGE 是永久删除、不可回滚的操作。
安全清理的关键是找到所有从库中「最旧未读日志」：
- 主库查当前写入点：
SHOW MASTER STATUS;→ 记下File字段（如mysql-bin.000042） - 每台从库执行：
SHOW SLAVE STATUS\G→ 看Relay_Master_Log_File和Exec_Master_Log_Pos - 取所有从库中
Relay_Master_Log_File序号最小的那个（比如mysql-bin.000035），这就是你PURGE TO的安全下限 - 执行：
PURGE BINARY LOGS TO 'mysql-bin.000036';（删掉 000036 之前的全部）
清理后磁盘空间没释放？大概率是句柄被 MySQL 进程占着
执行 PURGE 后 df -h 显示空间未变，不是命令失效，而是 Linux 下文件虽被 unlink，但 MySQL 进程仍持有打开句柄（lsof | grep deleted 可验证）。此时空间不会真正回收。
两种解法：
- 等 MySQL 主动轮转日志（比如执行
FLUSH BINARY LOGS，或触发主从切换） - 或直接重启 MySQL：
systemctl restart mysqld（宝塔面板点重启也行）
注意：RESET MASTER 绝对禁用——它会清空所有 binlog 并重置序列号，主从复制立刻中断，生产环境等于自断手脚。
宝塔定时脚本清理要绕开密码明文风险
很多宝塔用户写定时任务直接用 mysql -uroot -p$(cat /www/server/panel/database/default.pl) -e "PURGE ..."，但 default.pl 若权限不是 600，其他用户可读 root 密码，极其危险。
更稳妥的做法：
- 创建专用账号：
CREATE USER 'cleaner'@'localhost' IDENTIFIED BY 'xxx';
赋最小权限：GRANT REPLICATION CLIENT, SUPER ON *.* TO 'cleaner'@'localhost'; - 用配置文件传参：
mysql --defaults-extra-file=/www/server/mysql/cleaner.cnf -e "PURGE BINARY LOGS BEFORE '$(date -d '7 days ago' '+%Y-%m-%d %H:%M:%S')';" -
/www/server/mysql/cleaner.cnf内容为：[client] user=cleaner password=xxx
并立即设权限：
chmod 600 /www/server/mysql/cleaner.cnf
自动策略 + 安全脚本兜底，才是生产环境长期可控的方案。别指望一次 purge 就一劳永逸——过期参数设太小会断复制，设太大又压磁盘，7 天是多数场景的平衡点，但得结合你的备份周期和从库延迟来调。
