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 干预，但必须正确配置生命周期策略，否则磁盘爆满。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
核心配置项：
-
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 脚本本身没问题，但卡在权限或安全模块上。
