MySQL：Error reading relay log event for channel ‘‘: slave SQL thread was killed

喝醉酒的小白

于 2025-05-21 16:27:27 发布

阅读量665

点赞数 26

分类专栏： DBA 文章标签： mysql

本文链接：https://blog.csdn.net/hezuijiudexiaobai/article/details/148116630

版权

DBA 专栏收录该内容

868 篇文章

订阅专栏

目录标题

问题描述 & 初步排查
主库 Binlog 分析
SHOW SLAVE STATUS

问题描述 & 初步排查

从你提供的MySQL备库错误日志截图中，我们可以看出备库在执行主从复制过程中反复出现错误，导致复制线程频繁中断和重启。以下是日志中的主要问题和分析：

🧾 错误日志摘要与分析

1. 主从复制线程反复停止

Error reading relay log event for channel '': slave SQL thread was killed

分析：
SQL线程被中止，通常是因为上层检测到错误（如写入失败、格式不兼容）或人为干预。

2. 主从心跳数据不兼容

Unexpected master's heartbeat data: heartbeat is not compatible with local info

分析：
这表示主库发来的心跳包在从库无法识别。可能是因为：

主库与从库的MySQL版本不一致
使用了GTID但配置不同步
二进制日志格式不一致（如ROW vs MIXED）

3. 写入中继日志失败

Relay log write failure: could not queue event from master, Error_code: 1595

分析：
该错误说明从库尝试将主库事件写入中继日志失败。可能原因有：

磁盘写入权限或空间不足
文件系统问题或损坏
主库发送了不兼容的事件

4. MySQL用户凭据安全警告

Storing MySQL user name or password in the master info repository is not secure

分析：
这是安全警告，建议使用 START SLAVE USER='...' IDENTIFIED BY '...' 或设置 master_info_repository = TABLE 来避免明文密码。

🛠️ 解决方案建议

✅ 1. 检查主从MySQL版本一致性

使用以下命令：

SELECT VERSION();

建议主库和从库使用相同版本，特别是涉及GTID和binlog格式的功能。

✅ 2. 检查复制配置一致性

确保以下参数在主从两端一致：

binlog_format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON

root@localhost : (none) 14:50:42> show variables like "binlog_format";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.01 sec)

root@localhost : (none) 14:50:53> show variables like "gtid_mode";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+
1 row in set (0.01 sec)

root@localhost : (none) 14:51:00> show variables like "enforce_gtid_consistency";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| enforce_gtid_consistency | ON    |
+--------------------------+-------+
1 row in set (0.00 sec)

✅ 3. 检查磁盘空间与权限

df -h
ls -l /var/lib/mysql/data/relaylog/

确保有足够的磁盘空间
检查mysql用户是否有权限写入relay log目录

✅ 4. 重设复制（如果数据允许）

如果错误持续，可以尝试如下操作（需注意数据一致性问题）：

STOP SLAVE;
RESET SLAVE ALL;
CHANGE MASTER TO
  MASTER_HOST='your-master-ip',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.012414',
  MASTER_LOG_POS=3222654984;
START SLAVE;

注意：
此操作将重置复制配置，请确保数据同步点正确！

✅ 5. 查看MySQL错误代码说明

错误代码：

1595: Relay log write failure
1623: Event compatibility issue

可用：

perror 1595
perror 1623

以获得具体含义。

✅ 监控复制状态

SHOW SLAVE STATUS\G

重点查看以下字段：

Last_IO_Error
Last_SQL_Error
Seconds_Behind_Master
Relay_Log_File

如需进一步协助，可提供：

主从MySQL版本号
SHOW SLAVE STATUS\G完整输出
my.cnf的复制相关配置段落

主库 Binlog 分析

是的，既然你已经检查并确认了配置无误，但备库依然反复报错并提示中继日志写入失败和主从事件不兼容，主库的 binlog 很有可能存在异常或不兼容事件，此时在主库上手动分析 binlog 是一个非常好的下一步操作。

🧪 主库 Binlog 分析操作指南

📍目的：

定位导致复制中断的 binlog 事件，判断是否有：

不兼容的事件类型
格式错误
GTID不一致
错误或无效的 DDL/DML 操作

✅ 步骤一：定位出错的 binlog 文件和位置

从你的日志中看出出错位置：

log_file_name: mysql-bin.012414
position: 3222654984

✅ 步骤二：在主库使用 `mysqlbinlog` 工具查看该位置附近内容

mysqlbinlog --base64-output=DECODE-ROWS \
            --verbose \
            --start-position=3222654950 \
            --stop-position=3222655020 \
            /var/lib/mysql/mysql-bin.012414 > binlog_events.txt

🔎 分析点：

是否有非法或未知事件
是否有不兼容的 DDL
是否有事务中断
是否为GTID模式但事件未封装在GTID块中

✅ 步骤三：如果发现有异常事件，可选择跳过（不推荐长期使用）

在从库执行以下命令跳过错误事件（适用于临时跳过）：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

🛑 警告： 此操作会导致主从数据可能不一致。务必确保跳过的是非关键事务，比如日志写入、统计更新等。

✅ 步骤四：修改主库逻辑或重写事件（高级操作）

如果你确认 binlog 中的事件异常且为逻辑错误：

可考虑在主库手动修正记录并重新生成 binlog
或将主库的指定数据手动同步到从库后重新设定复制位点

🧰 工具推荐

mysqlbinlog：分析 binlog 文件的核心工具
pt-slave-restart（Percona Toolkit）：自动跳过复制错误（慎用）

📌 补充建议

✅ 开启 GTID 并使用 `AUTO_POSITION = 1`

这能提高主从同步容错能力：

CHANGE MASTER TO
  MASTER_HOST='...',
  MASTER_USER='...',
  MASTER_PASSWORD='...',
  MASTER_AUTO_POSITION = 1;

前提：主从都已启用 gtid_mode=ON 且 enforce_gtid_consistency=ON

SHOW SLAVE STATUS

谢谢你提供的 SHOW SLAVE STATUS\G 输出，非常关键。

✅ 当前状态总结

你的 MySQL 复制状态现在看起来是 正常的：

关键项	状态
`Slave_IO_Running`	Yes ✅
`Slave_SQL_Running`	Yes ✅
`Seconds_Behind_Master`	0 ✅
`Last_SQL_Error` / `Last_IO_Error`	空 ✅
`Slave_SQL_Running_State`	`Slave has read all relay log; waiting for more updates` ✅

说明当前主从复制已经恢复正常，之前日志中报的错误（如 relay log 写入失败、master 心跳不兼容等）已经不再发生。

🧠 状况解释（可能性）

这类问题常见原因及其后续正常的可能情景：

🟡 主库 binlog 临时异常

你之前日志中提到：

Relay log write failure: could not queue event from master, Error_code: 1595

这可能是因为：

binlog中某个事件临时写入失败（网络不稳、瞬时磁盘I/O问题）
心跳包格式异常导致从库不识别，但不是持续性的

系统自动重试后恢复成功。

🟡 从库自动恢复或错误事件已跳过

MySQL 8.0+ 在某些配置下可能自动跳过轻微非致命事件（如心跳包异常）。或你手动或间接使用了 sql_slave_skip_counter。

📌 下一步建议

✅ 1. 继续监控

建议使用如下脚本定时检查复制状态并报警（推荐每5分钟）：

#!/bin/bash
mysql -e "SHOW SLAVE STATUS\G" | egrep "Running|Behind|Error"

或者使用 Prometheus + mysqld_exporter + Alertmanager 来进行更系统化的监控。

✅ 2. 查看并保存异常 binlog 片段（可选）

为了确保未来问题复现时可追溯，建议：

导出出错时间段的 binlog 片段
使用 mysqlbinlog 分析是否存在逻辑错误

例如：

mysqlbinlog --start-datetime="2025-05-21 14:40:20" --stop-datetime="2025-05-21 14:40:50" \
  /var/lib/mysql/mysql-bin.012414 > /tmp/binlog_error_segment.sql