mysql日志rotate怎么配置_mysql日志轮转管理

logrotate 是管理 mysql 错误日志和慢查询日志轮转的事实标准，需正确配置路径、权限、sharedscripts 和 postrotate 中的 kill -usr1 信号，并避开 binlog。

确认日志路径和启用状态

别急着写 /etc/logrotate.d/mysql，先看 MySQL 实际在往哪写、写了哪些日志：

• 运行 mysql -u root -p -e "SHOW VARIABLES LIKE '%log%';"，重点关注 log_error、slow_query_log_file、general_log_file
• 检查这些路径是否真实存在，且 MySQL 进程有写权限（ls -l /var/log/mysql/ 看属主是不是 mysql:mysql）
• 如果 slow_query_log 或 general_log 是 OFF，logrotate 配置对应路径也没用——先在 [mysqld] 段启用并指定 slow-query-log-file 等参数，再重启 MySQL

写对 logrotate 配置的关键点

最常出问题的是 postrotate 脚本没生效，或权限/路径不匹配。一个稳妥的配置示例如下：

Blackink AI纹身生成

创建类似纹身的设计，生成独特纹身

下载

/var/log/mysql/error.log /var/log/mysql/slow.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 640 mysql mysql
    sharedscripts
    postrotate
        if [ -f /var/run/mysqld/mysqld.pid ]; then
            kill -USR1 $(cat /var/run/mysqld/mysqld.pid)
        fi
    endscript
}

• sharedscripts 必须加：否则多个日志文件会各自执行一次 postrotate，而 kill -USR1 只需发一次
• 用 kill -USR1 而非 mysqladmin flush-logs 更轻量，但要求 MySQL 启动方式支持该信号（mysqld_safe 或 systemd 管理的主流版本都支持）
• 如果 PID 文件路径不对（比如是 /var/run/mysqld.pid 或 /run/mysqld/mysqld.pid），脚本就静默失败——务必用 ps aux | grep mysqld 确认实际 PID 文件位置
• 避免用通配符如 /var/log/mysql/*.log，除非你 100% 确保目录下只有 MySQL 自己写的日志文件；混入其他服务日志可能被误删

测试与验证不能跳过

配置完别只信“它应该能跑”，得亲眼看到轮转发生且 MySQL 没断写：

• 用 sudo logrotate -d /etc/logrotate.d/mysql 查看调试输出，确认匹配到的日志路径、是否进入 postrotate 块
• 手动强制轮转：sudo logrotate -f /etc/logrotate.d/mysql，然后立刻检查：
  – 原日志（如 error.log）是否变为空或大小为 0？
  – 是否生成 error.log.1（未压缩）或 error.log.1.gz（已压缩）？
  – 新日志是否开始写入？用 tail -f /var/log/mysql/error.log 看是否有新记录
• 如果发现 MySQL 还在往 error.log.1 写，说明 postrotate 没成功发信号——常见原因是 PID 文件路径错、MySQL 进程没读取到 USR1、或 SELinux/AppArmor 拦截了信号

二进制日志（binlog）要单独对待

binlog 完全不走 logrotate 流程，它是 MySQL 自己管理的：

• 靠 max_binlog_size（默认 1GB）或时间（binlog_expire_logs_seconds）触发自动切换
• 不要把 binlog 文件路径（如 /var/lib/mysql/mysql-bin.*）加进 logrotate 配置——会导致 MySQL 写入异常甚至崩溃
• 清理用 PURGE BINARY LOGS，而不是 rm 或 logrotate 删除；推荐设 expire_logs_days = 7 让 MySQL 自动过期