MySQL日志轮转必须通过logrotate配合mysqladmin flush-logs实现：先确认log_error等路径及权限，配置中用postrotate调用mysqladmin flush-logs（禁用copytruncate和kill -USR1），设置rotate 7、compress、create 640 mysql adm，并通过logrotate -d和-f测试验证。
直接配 logrotate 不行，必须让 MySQL 主动“换本子”，否则轮转后它还在往旧文件句柄里写，磁盘空间根本不会释放。
先确认 MySQL 实际在写哪些日志和路径
别急着改配置，先看 MySQL 自己认的路径和开关状态：
- 运行
mysql -u root -p -e "SHOW VARIABLES LIKE '%log%';"，重点关注log_error、slow_query_log_file、general_log_file - 检查这些路径是否真实存在：
ls -l /var/log/mysql/，确保属主是mysql:mysql，且 MySQL 进程有写权限 - 如果
slow_query_log或general_log是OFF，logrotate配对应路径就是白忙——得先在[mysqld]段启用并指定文件路径，再重启 MySQL
logrotate 配置里必须用 postrotate + FLUSH LOGS
copytruncate 看似省事，但高并发下可能丢几行日志，且 MySQL 5.7+ 某些版本对截断后文件句柄处理不稳定。真正安全的做法是轮转完立刻通知 MySQL 关闭旧文件、打开新文件：
- 在
/etc/logrotate.d/mysql中写postrotate脚本，不是prerotate（顺序反了会丢最后几秒日志） - 推荐用
mysqladmin flush-logs，而不是kill -USR1：前者只刷 error log 和 slow log，后者会触发所有日志重开（包括 binlog，没必要） - 确保执行用户能连上 MySQL：
mysqladmin要么走 socket（如-S /var/run/mysqld/mysqld.sock），要么用专用账号（如flush-logs@localhost，仅授RELOAD权限）
配置示例与关键参数含义
以下是一个生产可用的 /etc/logrotate.d/mysql 片段（按实际路径调整）：
/var/log/mysql/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 640 mysql adm
sharedscripts
postrotate
if [ -f /var/run/mysqld/mysqld.pid ]; then
mysqladmin -S /var/run/mysqld/mysqld.sock flush-logs 2>/dev/null || true
fi
endscript
}
注意几个易错点：
-
create 640 mysql adm：新日志权限必须匹配 MySQL 进程预期，否则它写不进去 -
sharedscripts：多个日志文件（error.log、slow.log）共用一个postrotate，避免重复执行flush-logs -
delaycompress：压缩延后到下次轮转，方便紧急时快速查看上一份未压缩日志 - 不要加
maxsize：MySQL 错误日志不支持按大小自动切换，靠daily+flush-logs更可靠
测试和验证不能跳过
配完别等明天，立刻手动触发并验证效果：
- 用
sudo logrotate -d /etc/logrotate.d/mysql查看调试输出，确认路径、条件、脚本都命中 - 用
sudo logrotate -f /etc/logrotate.d/mysql强制执行一次，观察：/var/log/mysql/error.log.1是否生成、error.log是否变为空、df -h磁盘空间是否真正释放 - 查 MySQL 进程是否仍在写新文件：
lsof -p $(cat /var/run/mysqld/mysqld.pid) | grep mysql.*log，应只看到error.log（新文件），不应还有error.log.1
最常被忽略的是权限和 socket 路径——mysqladmin 报错不提示具体原因，只会静默失败，导致 postrotate 形同虚设。
