MySQL错误日志过大怎么处理_配置logrotate自动切割与清理

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简单配copytruncateMySQL 5.7 在某些版本下对截断后的文件句柄处理不稳定可能丢日志或写入失败推荐用create postrotate组合确保新日志权限正确、MySQL能立即写入新文件logrotate配置必须包含postrotate调用mysqladmin flush-logs只靠logrotate移动或重命名文件MySQL仍往旧文件描述符里写——得通知它“换新本子”。关键动作是mysqladmin flush-logs它会让mysqld关闭当前error.log并打开新的。注意不是FLUSH LOGS那个会刷所有日志包括binlog没必要。mysqladmin需有足够权限建议用专用低权账号如flush-logslocalhost仅授予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进程没读它。 Murf AI AI文本转语音生成工具