MySQL错误日志和慢查询日志需借助logrotate配合FLUSH命令实现轮换:配置logrotate daily并用postrotate执行FLUSH ERROR LOGS和FLUSH SLOW LOGS,确保create权限及SELinux策略适配;binlog则由MySQL自动轮换与expire_logs_seconds控制清理。

MySQL 的错误日志和慢查询日志如何启用轮换
MySQL 自身不提供像 Linux logrotate 那样的内置日志轮换机制,错误日志(error_log)和慢查询日志(slow_query_log_file)默认是追加写入的单个文件,长期运行会导致文件巨大、排查困难、备份耗时。要实现轮换,必须依赖外部工具或 MySQL 自带的有限命令。
关键点:MySQL 5.7+ 支持 FLUSH ERROR LOGS 和 FLUSH SLOW LOGS(需开启 slow_query_log),执行后会关闭当前日志文件并新建一个同名文件(注意:不是重命名,也不是压缩,只是“换新文件”)。这相当于手动触发轮换起点。
- 确保配置中已指定明确路径,例如:
log_error = /var/log/mysql/error.log,避免使用默认相对路径 - 慢查询日志需显式开启:
slow_query_log = ON,且设置slow_query_log_file = /var/log/mysql/mysql-slow.log - 执行
FLUSH ERROR LOGS后,原error.log不会自动改名或归档,需由外部脚本配合完成移动/压缩
用 logrotate 管理 MySQL 日志文件的实操要点
logrotate 是最常用、最稳妥的日志轮换方案,但 MySQL 进程持有日志文件句柄,直接轮换会导致新日志继续写入旧文件(因为文件描述符未刷新)。必须配合 create + postrotate 脚本通知 MySQL 重新打开日志。
典型 /etc/logrotate.d/mysql 配置示例:
"/var/log/mysql/error.log" "/var/log/mysql/mysql-slow.log" {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 mysql mysql
sharedscripts
postrotate
if test -n "$MYSQLD_PID" && kill -0 "$MYSQLD_PID" > /dev/null 2>&1; then
mysql -u root -p'your_password' -e "FLUSH ERROR LOGS;" >/dev/null 2>&1 || true
mysql -u root -p'your_password' -e "FLUSH SLOW LOGS;" >/dev/null 2>&1 || true
fi
endscript
}
-
sharedscripts确保多个日志文件共用一套postrotate,避免重复执行 - 密码硬编码不安全,建议改用
~/.my.cnf配置文件(权限600),并在命令中加--defaults-extra-file=/root/.my.cnf -
create参数必须存在,否则轮换后新文件权限/属主可能不对,导致 MySQL 写入失败 - 不要用
copytruncate:它会清空原文件,但 MySQL 可能因缓冲未刷盘而丢日志
binlog 日志轮换与过期清理的正确方式
二进制日志(binlog)的轮换机制和清理逻辑与错误日志完全不同:它由 MySQL 自动管理,无需 logrotate 干预,但必须正确配置生命周期策略,否则磁盘爆满。
核心配置项:
-
expire_logs_days = 7(已弃用,MySQL 8.0+ 推荐用binlog_expire_logs_seconds) -
binlog_expire_logs_seconds = 604800(即 7 天),MySQL 会定期扫描并删除超期 binlog 文件 -
max_binlog_size = 1073741824(1GB),控制单个 binlog 文件大小,达到后自动新建下一个 - 执行
SHOW BINARY LOGS;查看当前活跃 binlog 列表;PURGE BINARY LOGS TO 'mysql-bin.000010';或PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00';可手动清理
注意:expire_logs_* 设置只影响自动清理时机,不保证精确到秒;若从库延迟大,过早清理 binlog 会导致复制中断。
容易被忽略的权限与 SELinux 问题
即使配置全对,日志轮换仍可能静默失败——最常见的两个隐藏原因:文件权限和 SELinux 上下文。
- MySQL 进程(通常为
mysql用户)必须对日志目录有写权限,且对轮换后的归档目录(如/var/log/mysql/old/)有创建和写入权限 - 在启用 SELinux 的系统(如 CentOS/RHEL)上,
logrotate默认运行在system_u:system_r:logrotate_t:s0上下文,无法向 MySQL 日志目录写入归档文件,报错类似:error: error creating output file /var/log/mysql/error.log.1: Permission denied - 临时验证可执行:
setenforce 0,若轮换恢复则确认是 SELinux 问题;长期解决应添加自定义策略:audit2allow -a -M mysql_logrotate,然后semodule -i mysql_logrotate.pp
实际运维中,比语法错误更难定位的是这些环境层约束——尤其是跨发行版迁移或容器化部署时,logrotate 脚本本身没问题,但卡在权限或安全模块上。











