17370845950

MySQL binlog必须用PURGE命令或binlog_expire_logs_seconds配置清理，严禁rm删除；error log和slow log需用logrotate+copytruncate或FLUSH命令轮转，且须确保主从同步完成后再清理binlog。

MySQL 的 binlog 日志如何安全清理

直接 rm -f 删除 binlog 文件会破坏 MySQL 复制和恢复能力，必须通过 SQL 命令或配置自动过期控制。

• 查看当前 binlog 列表：SHOW BINARY LOGS;
• 删除指定日志前的所有 binlog（不含该文件）：PURGE BINARY LOGS TO 'mysql-bin.000010';
• 按时间清理：比如保留最近 7 天的 binlog：PURGE BINARY L

  

  OGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);
• 执行前务必确认从库已同步完成（SHOW SLAVE STATUS\G 中 Relay_Master_Log_File ≤ 要保留的 binlog 文件名）

设置 binlog 自动过期时间（expire_logs_days 已弃用）

MySQL 8.0.11+ 推荐使用 binlog_expire_logs_seconds 替代旧参数，精度更高且支持秒级控制。

SET PERSIST binlog_expire_logs_seconds = 604800;  -- 7 天，单位：秒
-- 永久生效需写入 my.cnf：
# [mysqld]
# binlog_expire_logs_seconds = 604800

• 旧参数 expire_logs_days 在 8.0.11+ 仍可读，但写入时会被忽略或转为等效的 binlog_expire_logs_seconds
• 设置值为 0 表示不自动清理，此时必须手动 PURGE，否则磁盘可能被撑爆
• 该参数只影响 binlog，不影响 error log 或 slow query log

错误日志（error log）轮转不靠 MySQL 内置机制

MySQL 本身不提供 error log 的自动轮转，依赖外部工具（如 logrotate）或手动触发 FLUSH ERROR LOGS。

• 手动轮转（生成新 error log，旧文件保留在原路径）：FLUSH ERROR LOGS;
• Linux 下推荐用 logrotate 配合 copytruncate，避免中断 MySQL 进程：

/var/log/mysql/error.log {
    daily
    missingok
    rotate 30
    compress
    copytruncate
    create 640 mysql mysql
}

• copytruncate 是关键：先拷贝再清空原文件，MySQL 不需要重启或重定向句柄
• 不要用 rename 类方式直接移动 error log，MySQL 不会自动创建新文件
• 检查 my.cnf 中 log_error 路径是否与 logrotate 配置一致

慢查询日志（slow query log）轮转与清理要点

慢查询日志默认不轮转，开启后若长期不处理，单个文件极易达到 GB 级别。

• 启用并指定路径：SET GLOBAL slow_query_log = ON; SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';
• 轮转方式同 error log：用 logrotate + copytruncate，或先关闭再重命名再开启：

SET GLOBAL slow_query_log = OFF;
-- mv /var/log/mysql/mysql-slow.log /var/log/mysql/mysql-slow.log.20250501
SET GLOBAL slow_query_log = ON;

• 注意：MySQL 不会自动压缩或删除历史 slow log，全靠运维策略
• 如果启用了 log_output = TABLE（写入 mysql.slow_log 表），则需定期 TRUNCATE TABLE mysql.slow_log;，而非文件操作

MySQL 日志管理最易被忽略的是 binlog 清理与主从同步状态的耦合——删早了从库追不上，删晚了磁盘爆掉。error log 和 slow log 轮转则常因依赖 FLUSH 命令却未配合外部工具而失效。