relay_log_info_repository=TABLE时slave_relay_log_info表损坏表现为START SLAVE后Slave_SQL_Running立即为No、Last_SQL_Error提示解析失败，但IO线程正常而Exec_Master_Log_Pos卡死；修复需STOP SLAVE后用SHOW SLAVE STATUS获取可信坐标，再UPDATE表中Master_log_name、Master_log_pos、Relay_log_name（须与磁盘文件一致）、Relay_log_pos=4及Channel_name，最后验证Relay_Log_File是否匹配且错误日志无目标日志未找到报错。
relay_log_info_repository=TABLE时，slave_relay_log_info表损坏的典型表现
当relay_log_info_repository设为TABLE（即中继日志位点存于mysql.slave_relay_log_info表），该表损坏后不会报“文件找不到”，而是出现更隐蔽的异常：START SLAVE后Slave_SQL_Running立即变为No，Last_SQL_Error显示类似Could not parse relay log event entry或Relay log read failure；但SHOW SLAVE STATUS\G中Master_Log_File和Read_Master_Log_Pos仍在增长（说明IO线程正常），而Exec_Master_Log_Pos卡死不动、Relay_Log_File为空——这是位点元数据错乱的明确信号。
不能直接TRUNCATE或DROP slave_relay_log_info表
该表结构受MySQL内部强约束，手动清空会破坏复制状态一致性。常见误操作包括：
- 执行
TRUNCATE TABLE mysql.slave_relay_log_info，导致SQL线程启动时读不到合法起点，报Failed to open the relay log - 用
DROP TABLE删掉再重建，但MySQL不会自动初始化字段值，START SLAVE直接失败 - 仅更新
Master_log_name和Master_log_pos字段，却忽略Channel_name（多源复制下必须匹配）、Relay_log_name（需与磁盘真实文件一致）等关键列
安全修复slave_relay_log_info表的三步实操
核心是让表中记录与当前IO线程拉取进度、磁盘上真实存在的relay log文件完全对齐：
- 先停稳复制：
STOP SLAVE;，并确认SHOW PROCESSLIST中无Slave_IO_Running进程 - 查出可信坐标：运行
SHOW SLAVE STATUS\G，记下Master_Log_File（如mysql-bin.000123）和Read_Master_Log_Pos（如456789）——这是IO线程最新拉到的位置，也是SQL线程唯一可安全接续的起点 - 重写位点表：执行
UPDATE mysql.slave_relay_log_info SET Master_log_name = 'mysql-bin.000123', Master_log_pos = 456789, Relay_log_name = 'hostname-relay-bin.000042', Relay_log_pos = 4 WHERE Channel_name = '';（单源复制Channel_name为空字符串；多源请替换对应channel名）
注意：Relay_log_name必须填磁盘上实际存在的最新relay log文件名（用ls -1v /var/lib/mysql/hostname-relay-bin.[0-9]* | tail -n1确认），且Relay_log_pos设为4（binlog文件头固定偏移）。
修复后必须验证的两个硬性条件
表改完不等于修复成功，MySQL是否真正加载新位点，得看运行态反馈：
-
START SLAVE;后立刻查SHOW SLAVE STATUS\G，确认Relay_Log_File与你刚填入Relay_log_name一致，且Relay_Log_Pos > 4（说明已开始读取有效事件） - 检查错误日志有无
Could not find target log during relay log initialization——这代表Relay_log_name写的文件在磁盘上不存在，需重新核对ls结果
最易被忽略的是relay_log_info_repository配置本身：若my.cnf里没显式写relay_log_info_repository=TABLE，MySQL启动时仍按默认FILE模式加载，表里的修改完全无效。
