不能直接删除relay-bin.*文件，因为relay-log是已拉取但未执行的关键中继日志，损坏后sql线程卡在非法偏移，删文件重启io线程无法重建有效中继日志，会导致复制断裂或事务丢失。
Relay Log损坏不能删了重拉，必须用RESET SLAVE + CHANGE MASTER TO组合重置SQL线程起点，否则会丢事件或跳过事务。
为什么不能直接删除 relay-bin.* 文件
relay-log不是缓存，是已拉取但未执行的中继日志。一旦损坏，Slave_SQL_Running会卡死在非法偏移，Relay_Log_Pos指向损坏文件内部无效位置。此时手动删文件、重启IO_THREAD，MySQL不会自动重建有效中继日志——因为IO_THREAD仍按原Master_Log_File/Master_Log_Pos继续拉取，而SQL_THREAD已失去上下文，极易导致复制断裂或事务丢失。
- 常见误操作：看到
Last_SQL_Error含Could not parse relay log event entry就直接rm -f hostname-relay-bin.* - 典型后果：
START SLAVE后Seconds_Behind_Master变NULL，或Relay_Master_Log_File不再更新 - 根本原因：
RESET SLAVE前未记录Master_Log_File和Master_Log_Pos，后续无法对齐执行起点
如何确认真是 relay-log 损坏而非其他问题
先排除 IO 线程异常或网络问题，避免误判。关键看SHOW SLAVE STATUS\G中两个字段状态：
- 若
Slave_IO_Running: No，重点查Last_IO_Error——比如error connecting to master或Could not find first log file name in binary log index file，这类跟 relay-log 无关 - 若
Slave_IO_Running: Yes但Slave_SQL_Running: No，再看Last_SQL_Error：出现Corrupted replication event或log event entry exceeded max_allowed_packet才较可能是解析失败 - 辅助验证：用
mysqlbinlog尝试解析当前Relay_Log_File，如报Invalid replication event或Failed to open file，基本坐实损坏
安全重置 relay-log 并重新定位 SQL 线程
核心是让SQL_THREAD从IO_THREAD已拉取的最新位置（即Master_Log_File/Master_Log_Pos）开始执行，不丢、不重、不越界。
- 执行
STOP SLAVE;，确保双线程都停稳 - 运行
SHOW SLAVE STATUS\G，记下Master_Log_File（如mysql-bin.000123）和Master_Log_Pos（如456789）——这是唯一可信的“已同步到主库哪”的坐标 - 执行
RESET SLAVE;：清空所有relay-bin.*和relay-log.index，重置Relay_Master_Log_File和Exec_Master_Log_Pos（注意：Master_Log_File/Master_Log_Pos不变） - 执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789;：把SQL_THREAD起点设回 IO 已拉取的位置 - 最后
START SLAVE;，并立刻检查SHOW SLAVE STATUS\G中Slave_SQL_Running是否为Yes、Seconds_Behind_Master是否开始下降
GTID模式下 relay-log 损坏怎么处理
GTID模式不依赖文件名+偏移，但RESET SLAVE仍会清空gtid_executed和gtid_purged，所以不能直接套用非GTID流程。必须先确认SELECT @@gtid_executed;和SELECT @@gtid_purged;值，并在RESET SLAVE后用SET GLOBAL gtid_purged = '...';补全（注意该变量只读，需SET SQL_LOG_BIN = 0;临时关闭 binlog 才能设置）。更稳妥的做法是：停复制 → 记录Retrieved_Gtid_Set和Executed_Gtid_Set → RESET SLAVE → SET GLOBAL gtid_purged = 'Executed_Gtid_Set值'; → START SLAVE;。
最易被忽略的是：RESET SLAVE在GTID模式下会清空slave_relay_log_info表中的位置信息，如果没提前备份Retrieved_Gtid_Set，SQL线程可能从空集合开始重放，导致重复执行或主键冲突。
