6.4.2 错误日志配置与故障定位实践

错误日志配置与故障定位实践#

错误日志用于记录 mysqld 启动、关闭、崩溃、权限、表损坏、复制异常等核心事件，是故障定位的第一入口。本节给出配置、排错流程与可执行示例。

一、错误日志原理草图（数据流与定位入口）

二、配置与规范（含完整示例）
1. my.cnf 配置示例

# /etc/my.cnf
[mysqld]
log_error=/var/log/mysql/mysql-error.log
log_error_verbosity=2
log_timestamps=SYSTEM
log_error_suppression_list=MY-010055,MY-013360

# 创建日志目录与授权
sudo mkdir -p /var/log/mysql
sudo chown -R mysql:mysql /var/log/mysql
sudo chmod 750 /var/log/mysql

# 重启生效
sudo systemctl restart mysqld

校验配置是否生效

mysql -uroot -p -e "SHOW VARIABLES LIKE 'log_error%';"
# 预期：log_error 指向 /var/log/mysql/mysql-error.log

三、典型故障场景与定位（命令+示例+解释）
1. 启动失败（端口占用/权限）

# 查看端口占用
sudo ss -lntp | grep 3306
# 解释：若有其他进程占用，需停止或更换端口

# 查看服务状态与最后错误
sudo systemctl status mysqld -l
sudo tail -n 50 /var/log/mysql/mysql-error.log

日志示例：

[ERROR] Can't start server: Bind on TCP/IP port: Address already in use

处理思路：释放 3306 或修改 port，再重启。

崩溃与自动恢复

sudo tail -n 80 /var/log/mysql/mysql-error.log

日志示例：

[ERROR] mysqld got signal 11;
[Note] InnoDB: Crash recovery finished.

解释：出现 signal 11 可能与硬件、内存或页损坏相关；确认系统日志与内存压力。

dmesg -T | tail -n 50

表损坏与 InnoDB 强制恢复（演练示例）

# /etc/my.cnf 临时加入
[mysqld]
innodb_force_recovery=1

sudo systemctl restart mysqld
# 导出受损库后恢复
mysqldump -uroot -p --databases testdb > /tmp/testdb.sql
# 去掉 innodb_force_recovery 并重启

解释：innodb_force_recovery 仅用于紧急导出，值越大风险越高。

复制异常定位

mysql -uroot -p -e "SHOW REPLICA STATUS\G"
# 关注：Replica_SQL_Running / Last_SQL_Error / Relay_Log_File

结合错误日志关键词：

[ERROR] Slave SQL thread aborted due to error 1062

解释：错误 1062 为主从冲突，需修复数据或跳过错误。

权限与认证问题

mysql -uroot -p -e "SELECT user,host,plugin FROM mysql.user;"

日志示例：

[ERROR] Access denied for user 'app'@'10.0.0.5'

解释：检查账号、授权与 skip_name_resolve 影响。

四、日志检索与关键命令（实操模板）

# 按时间范围检索（示例：最近 1 小时）
sudo awk 'BEGIN{cmd="date -d \"1 hour ago\" \"+%Y-%m-%dT%H:%M\""; cmd | getline t; close(cmd)}
$0>=t' /var/log/mysql/mysql-error.log | tail -n 50

# 关键字过滤
sudo grep -E "ERROR|InnoDB|signal|crash" /var/log/mysql/mysql-error.log | tail -n 50

五、日志轮转与容量控制（完整示例）

# /etc/logrotate.d/mysql-error
/var/log/mysql/mysql-error.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 mysql mysql
    postrotate
        systemctl kill -s HUP mysqld || true
    endscript
}

sudo logrotate -f /etc/logrotate.d/mysql-error
# 预期：生成 mysql-error.log.1.gz 等文件

六、故障定位流程（可落地步骤）
1. 时间对齐：确认 log_timestamps=SYSTEM，对齐系统日志。
2. 事件溯源：错误日志 → 系统日志（dmesg//var/log/messages）。
3. 影响评估：是否影响写入、复制、连接或一致性。
4. 恢复优先：保证服务恢复后再追根因。
5. 记录复盘：故障时间线、影响范围、修复与改进措施。

七、练习与自测
1. 练习1：模拟端口冲突

# 启动一个占用 3306 的临时服务
sudo nc -l 3306 &
sudo systemctl restart mysqld
# 观察错误日志并恢复
sudo kill %1
sudo systemctl restart mysqld

练习2：触发权限错误

mysql -uroot -p -e "REVOKE ALL ON *.* FROM 'app'@'10.0.0.%';"
mysql -uapp -p -h 127.0.0.1 -e "SELECT 1;"
# 查看错误日志并恢复授权

八、最佳实践
- 错误日志放独立分区，避免磁盘写满影响数据文件。
- 关键关键词与监控告警联动（如 mysqld got signal、Crash、Disk is full）。
- 定期演练并固化故障定位流程，形成可复用 SOP。