误删从库relay-log后应停止sql线程、记录master_log_file和read_master_log_pos、执行reset slave清空中继日志、再用change master to指向该位置重启sql线程，gtid模式需先禁用auto_position。
误删从库的 relay-log 文件会导致复制完全中断，常见报错如 Relay log read failure、Could not parse relay log event entry 或直接卡在 Slave_SQL_Running: No 且 Last_SQL_Error 指向非法偏移。这不是简单重启能解决的问题——relay-log 是中继日志，不是缓存，它承载了已拉取但尚未执行的全部变更事件。删掉它，等于丢失“待办清单”，SQL 线程无从知道该从哪继续。
先确认是否真丢了，别误判
很多“删了 relay-log”其实是连锁反应：IO 线程早因网络或主库问题停了，relay-log 停滞不更新，崩溃后又误以为是文件损坏。务必分步验证：
- 执行 SHOW SLAVE STATUS\G，看 Slave_IO_Running 是否为 Yes；若为 No，重点查 Last_IO_Error（比如连接超时、认证失败），这类问题跟 relay-log 无关
- 若 Slave_IO_Running: Yes 但 Slave_SQL_Running: No，再看 Last_SQL_Error 是否含 Corrupted replication event 或 log event entry exceeded max_allowed_packet
- 手动检查磁盘：ls -l $(SELECT @@relay_log_basename; | awk '{print $2}')*，确认文件确实缺失；再用 mysqlbinlog /path/to/missing-relay-bin.0000xx | head -5 尝试解析现存文件，报错才说明损坏
核心原则：不丢数据、不跳事务、不依赖旧位点
删了 relay-log 后，Relay_Master_Log_File 和 Exec_Master_Log_Pos 已失效，不能拿来重设。唯一可信的是 IO 线程当前拉到的位置——即 Master_Log_File 和 Read_Master_Log_Pos。它们代表“主库 binlog 中，从库已成功接收但还没来得及执行的部分”的终点。
- STOP SLAVE SQL_THREAD; —— 只停 SQL 线程，保留 IO 线程继续接收新日志
- 记下 SHOW SLAVE STATUS\G 中的 Master_Log_File（如 mysql-bin.001078）和 Read_Master_Log_Pos（如 670812995）
- 执行 RESET SLAVE; —— 它会清空所有 relay-log 文件、重置 relay-log.index，并把 Relay_Master_Log_File 和 Exec_Master_Log_Pos 归零，但 不碰 Master_Log_File / Read_Master_Log_Pos
- 执行 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001078', MASTER_LOG_POS=670812995; —— 让 SQL 线程从此处开始解析执行
- START SLAVE SQL_THREAD;
GTID 模式下要多走两步
如果启用了 AUTO_POSITION=1，直接执行 CHANGE MASTER TO MASTER_LOG_FILE 会报错 ERROR 1776。必须先退出 GTID 自动定位模式：
- CHANGE MASTER TO MASTER_AUTO_POSITION = 0;
- RESET SLAVE;
- 再用 Master_Log_File 和 Read_Master_Log_Pos 执行 CHANGE MASTER TO
- 可选：恢复 GTID 模式前，需补全 gtid_purged（用 SELECT @@gtid_executed; 对比主库，必要时 SET GLOBAL gtid_purged = '...';）
重建 relay-log.index 的细节不能漏
RESET SLAVE 会删掉索引文件，但 MySQL 不会自动重建它。若你发现 START SLAVE 后报 Could not read from relay log index file，说明索引没生成或路径不对：
- 进数据目录：cd $(SELECT @@datadir; | awk '{print $2}')，再 cd 到 $(SELECT @@relay_log_basename; | awk '{print $2}')* 所在路径
- 执行：ls -1v *-relay-bin.[0-9]* > relay-log.index（-v 确保 000010 排在 00002 后面）
- 核对：head -n 2 relay-log.index 看是否为合法文件名、无空行、无乱码
- 确认变量：SELECT @@relay_log_index; 输出路径必须和你刚写的文件一致
整个过程不复杂但容易忽略权限和顺序。只要 IO 线程还在运行，就能保住最新拉取位置；只要索引文件真实反映磁盘现状，SQL 线程就能重新接上。不需要 dump，也不用重建从库。
