如何解决MySQL生产环境由于Binlog占用磁盘过大问题_调整expire_logs

mysql 8.0+ 必须使用 binlog_expire_logs_seconds（如604800秒），expire_logs_days 已废弃且设则报错3683；手动清理前须核对主从最旧未读日志，purge 后空间未释放需 flush 或重启释放句柄。

如何解决mysql生产环境由于binlog占用磁盘过大问题_调整expire_logs_days参数

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

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

等 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 天是多数场景的平衡点，但得结合你的备份周期和从库延迟来调。