MySQL 5.7主从复制强杀后不会自动恢复，需依赖relay_log_info_repository=TABLE、master_info_repository=TABLE和relay_log_recovery=1配置实现自愈；若为FILE模式则极易失败，必须人工干预重配。
MySQL 5.7 主从复制在强杀 mysqld 进程后，**不会自动恢复复制状态**，必须人工干预；但是否需要手动重配，取决于是否启用 relay_log_info_repository=TABLE 和 master_info_repository=TABLE，以及是否开启 relay_log_recovery=1。
强杀后 SQL 线程不启动：检查 relay log 恢复机制是否生效
MySQL 5.7 默认启用 relay_log_recovery=1（5.7.4+ 版本），但该参数仅在服务正常关闭时才被绕过；强杀会导致中继日志（relay log）与 SQL 线程执行位置不一致，此时若未配置表存储元数据，从库重启后可能卡在 Slave_SQL_Running: No，且 Relay_Log_Pos 停滞。
- 确认是否启用表方式存储复制位点：
SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('master_info_repository', 'relay_log_info_repository');—— 两值都应为TABLE - 若为
FILE（即写入master.info/relay-log.info），强杀极易导致文件损坏或位置错乱，重启后复制大概率失败 -
relay_log_recovery=1在启动时会丢弃当前relay log，让 I/O 线程从SQL thread已执行的位点重新拉取 —— 这是自愈关键，但前提是relay_log_info_repository=TABLE已启用，否则无法可靠读取上一次执行位置
SHOW SLAVE STATUS\G 卡住或返回空：global_sid_lock 锁争用
重启后首次执行 SHOW SLAVE STATUS\G 卡住，常见于 GTID 模式下多个线程争抢 global_sid_lock 写锁，尤其当监控脚本（如 Zabbix）同时调用 SHOW MASTER STATUS 时。
- 现象：
SHOW PROCESSLIST中出现State: Waiting for global read lock或栈中含global_sid_lock->wrlock() - 临时解法：停掉所有定时轮询主从状态的外部脚本，再执行
SHOW SLAVE STATUS\G - 长期规避：升级到 MySQL 5.7.41+（已优化该锁路径），或为监控账号单独配置只读权限、避免混用复制账号
SQL 线程报 1032/1062 错误且 Seconds_Behind_Master 为 NULL
这不是自愈失败，而是数据已不一致的明确信号 —— 强杀可能中断了事务回放，导致行级状态错位（尤其无主键表 + 并行复制），后续事件直接找不到目标行或冲突。
-
Error_code: 1032：常见于UPDATE/DELETE找不到记录，根源常是隐式row_id不一致或缺失主键 -
Error_code: 1062：主键冲突，说明从库被误写，或主库补写了重复 ID 数据 - 不要直接
SET GLOBAL sql_slave_skip_counter = 1—— 跳过只是掩盖问题，下次还报；优先补主键：ALTER TABLE t ADD id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST; - GTID 模式下不能跳过，需用
SET GTID_NEXT='xxx'; BEGIN; COMMIT;伪造已执行事务，再START SLAVE;
IO 线程连不上主库：检查 master.info 是否残留错误连接信息
若 master_info_repository=FILE，强杀可能让 master.info 文件写入一半，重启后从库仍尝试连一个已失效的旧 IP 或端口。
- 查看文件内容：
cat /var/lib/mysql/master.info（路径依实际配置而定），确认前几行的 host、port、user 是否正确 - 若内容异常（如字段错位、端口为 0、密码为空），必须先
STOP SLAVE;，再CHANGE MASTER TO重置连接参数 - 更稳妥做法：统一启用
master_info_repository=TABLE，避免文件 IO 中断引发元数据损坏
真正决定“能否自愈”的不是 MySQL 版本，而是 relay_log_info_repository 和 master_info_repository 是否设为 TABLE，以及 relay_log_recovery 是否开启 —— 其他所有表现（卡住、报错、延迟归零）都是这些配置是否落地的结果。强杀不可逆，但配置可预防。
