MySQL错误日志需用logrotate配合mysqladmin flush-logs实现安全轮转，关键在于路径一致、create指定正确用户组、postrotate通知MySQL切日志，否则磁盘会被撑爆或日志丢失。
MySQL错误日志没配logrotate会撑爆磁盘
MySQL默认不自动轮转错误日志（error.log），尤其在高并发或频繁报错的环境里，几个月就能涨到几十GB。最直接的表现是磁盘使用率突然飙升，df -h一看/var或/var/log分区快满了，但du -sh /var/log/mysql又明显对不上——其实是因为error.log被mysqld进程独占写入，rm或mv后空间不释放，必须触发日志重开。
- MySQL自身不支持按大小轮转错误日志，
FLUSH ERROR LOGS只能清空当前文件并新建，但没清理旧文件的逻辑 - 不能依赖
logrotate简单配copytruncate：MySQL 5.7+ 在某些版本下对截断后的文件句柄处理不稳定，可能丢日志或写入失败 - 推荐用
create+postrotate组合，确保新日志权限正确、MySQL能立即写入新文件
logrotate配置必须包含postrotate调用mysqladmin flush-logs
只靠logrotate移动或重命名文件，MySQL仍往旧文件描述符里写——得通知它“换新本子”。关键动作是mysqladmin flush-logs，它会让mysqld关闭当前error.log并打开新的。注意不是FLUSH LOGS（那个会刷所有日志，包括binlog，没必要）。
-
mysqladmin需有足够权限：建议用专用低权账号，如flush-logs@localhost，仅授予RELOAD权限 - 配置中必须用
postrotate而非prerotate：先轮转文件，再通知MySQL切日志，顺序反了会丢最后几秒日志 - 避免用
kill -USR1发信号：不同MySQL版本对信号支持不一，mysqladmin更兼容
/var/log/mysql/error.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 mysql mysql
sharedscripts
postrotate
if test -f /var/run/mysqld/mysqld.pid; then
mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs 2>/dev/null || true
fi
endscript
}
检查error.log路径和mysqld实际加载的配置
很多人配完logrotate没效果，第一反应是脚本错了——其实常是MySQL压根没在写你认为的那个error.log。比如Docker容器里路径映射错、systemd启动时用--log-error=/var/lib/mysql/host.err覆盖了my.cnf设置、或者Ubuntu系默认用debian.cnf指向/var/log/mysql/error.log但实际MySQL进程没读它。
- 查真实路径：
mysql -e "SHOW VARIABLES LIKE 'log_error';"，返回值才是MySQL正在写的文件 - 确认logrotate配置路径和上一步完全一致，包括软链接目标（
ls -l /var/log/mysql/error.log） - systemd用户要检查
systemctl show mysqld | grep Environment，看是否通过Environment=MYSQL_LOG_ERROR=...硬编码了路径
rotate后日志权限错导致mysqld无法写入新文件
logrotate默认用create重建文件，但如果create参数漏写用户/组（如只写create 640），新文件会属root:root，而mysqld通常以mysql用户运行，一写就失败，错误日志反而停更——这时候你会看到磁盘不涨了，但MySQL也不记错了，排查更隐蔽。
- 务必写全
create 640 mysql mysql，用户组名必须和ps aux | grep mysqld显示的启动用户一致 - 如果MySQL跑在容器或非标准用户下（如
mysqld_user:mysqld_group），create参数也得同步改 - 测试配置是否生效：
logrotate -d /etc/logrotate.d/mysql看调试输出，重点确认creating new /var/log/mysql/error.log mode = 0640 uid = 123 gid = 127里的uid/gid对不对
