首先检查MySQL日志配置及路径，确认log_error和slow_query_log设置正确；接着验证logrotate配置文件是否存在并包含正确的日志路径与postrotate指令，确保其调用reload-log或kill -HUP通知MySQL重载日志；然后通过logrotate -d和-f测试轮转功能，检查是否生成压缩归档文件且MySQL继续写入新日志；最后排查权限问题、systemd日志重定向影响以及binlog的独立过期策略，确保日志目录可写、信号送达、长期运行实例能响应日志轮转。

MySQL日志轮转问题通常表现为日志文件过大、旧日志未归档或删除、磁盘空间耗尽等。排查这类问题需要从配置、系统行为和日志管理机制入手，以下是具体排查方法。

检查MySQL的错误日志和慢查询日志配置

确认MySQL是否启用了相关日志以及日志路径设置是否正确：

• 登录MySQL执行 SHOW VARIABLES LIKE ‘log_error’; 查看错误日志路径
• 执行 SHOW VARIABLES LIKE ‘slow_query_log%’; 确认慢查询日志是否开启及路径
• 查看 my.cnf 或 my.ini 配置文件中的 log-error、slow-query-log-file 等参数

确保日志路径指向合理位置，避免写入系统敏感目录或空间不足的分区。

确认日志轮转工具是否生效

Linux系统通常使用 logrotate 管理MySQL日志轮转，需检查其配置：

AI建筑知识问答

用人工智能ChatGPT帮你解答所有建筑问题

22

查看详情

• 查看 /etc/logrotate.d/mysql-server 或 /etc/logrotate.d/mysqld 是否存在
• 确认配置中包含正确的日志路径，例如：
  /var/log/mysql/error.log {
  daily
  rotate 7
  compress
  missingok
  notifempty
  create 640 mysql adm
  postrotate
  if invoke-rc.d mysql status > /dev/null 2>&1; then
  invoke-rc.d mysql reload-log > /dev/null 2>&1
  fi
  endscript
  }
• 重点检查 postrotate 中是否调用 reload-log 或 kill -HUP 向MySQL发送信号，否则MySQL不会切换日志文件

手动测试logrotate运行情况

验证logrotate能否正常工作：

• 执行命令 logrotate -d /etc/logrotate.d/mysql-server 进行调试模式运行，观察输出流程
• 加入 -f 参数强制执行一次轮转：logrotate -f /etc/logrotate.d/mysql-server
• 执行后检查日志目录，确认是否生成 .1、.2.gz 等轮转文件
• 查看MySQL是否继续写入新日志（原文件被重命名后，MySQL应通过 reload-log 重新打开新文件）

监控与常见问题处理

实际环境中容易忽略的关键点：

• MySQL用户对日志目录是否有写权限？轮转时 create 指令需要权限创建新文件
• 如果使用了 systemd 管理MySQL，部分发行版会将日志重定向到 journald，此时文件轮转可能无效
• 二进制日志（binlog）由 expire_logs_days 或 binlog_expire_logs_seconds 控制，不属于 logrotate 范畴，需单独设置
• 长期未重启的MySQL实例，在日志被外部移动后未收到 HUP 信号，会导致日志“消失”——实际仍在写原inode

基本上就这些。关键是确认 logrotate 配置存在、权限正确、postrotate 能通知MySQL重载日志。只要信号送达，MySQL就会关闭旧句柄并打开新文件，实现真正的轮转。