主从复制中断后，如何安全跳过错误继续同步
主从复制因 SQL 线程报错而停止（如
Slave_SQL_Running: No），常见于主库执行了从库不存在的表、字段或违反唯一约束的操作。此时不能直接
START SLAVE，必须先确认错误性质。
执行
SHOW SLAVE STATUS\G，重点看：
Seconds_Behind_Master（是否已追平）、
SQL_Delay（是否有延迟复制）、
Last_SQL_Error（具体错误文本）。 若错误是「重复键」或「记录不存在」且业务可接受数据微小不一致，可用
SET GLOBAL sql_slave_skip_counter = 1跳过当前事件（仅对基于语句复制 SBR 有效） 若为基于行复制（RBR），需用
mysqlbinlog解析主库 binlog 定位出问题的 event，再在从库手工补数据或跳过——
sql_slave_skip_counter对 RBR 无效 跳过前务必备份从库当前数据，跳过操作不可逆
主库误删库/表后，如何从从库快速恢复
从库本身不是备份，但若开启
log_slave_updates且保留完整 relay log 或 binlog，可作为恢复源。关键前提是：从库未启用
read_only=ON（否则无法写入），或临时关闭。 停掉从库复制：
STOP SLAVE;确认从库数据最新位置：
SHOW SLAVE STATUS\G中的
Relay_Master_Log_File和
Exec_Master_Log_Pos导出所需库表：
mysqldump --single-transaction --databases db_name > restore.sql（注意加
--single-transaction避免锁表） 导入到主库前，先停写或切走流量；若主库启用了 GTID，导入后需重置复制：
RESET SLAVE ALL;+
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1;
从库数据损坏或磁盘故障，重建从库最稳的方式
比尝试修复更可靠的是重新搭建：用主库当前一致快照 + 主库最新 binlog 位置，构建新从库。避免 relay log 损坏、GTID 不连续等隐性问题。
主库上执行FLUSH TABLES WITH READ LOCK;，记下
SHOW MASTER STATUS输出的
File和
Position另起会话执行
mysqldump --all-databases --master-data=2 --single-transaction > full_backup.sql（
--master-data=2会把 CHANGE MASTER 语句注释写入 dump 文件） 解锁：
UNLOCK TABLES;在新从库导入：
mysql ，然后解析 dump 文件找到 <code>CHANGE MASTER TO行，去掉注释并执行 启动复制：
START SLAVE;，检查
Seconds_Behind_Master是否下降
GTID 模式下跳过事务或注入空事务的注意事项
GTID 复制中不能用
sql_slave_skip_counter，必须用空事务替代被跳过的 GTID。否则从库会卡在「waiting for gtid set」状态。 查出要跳过的 GTID：
SHOW SLAVE STATUS\G中的
Retrieved_Gtid_Set和
Executed_Gtid_Set对比，找出缺失项 在从库执行：
SET GTID_NEXT='xxx-xxx-xxx:nnn'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';（xxx-xxx-xxx 是 UUID，nnn 是事务号） 之后
START SLAVE;才能继续 如果 GTID 不匹配（比如主库重建过），可能需
RESET MASTER;并重设复制，但会丢失所有本地 binlog —— 此操作极危险，仅限测试环境或完全确认无其他从库依赖时使用 实际恢复中最容易被忽略的是：没确认主从是否真的处于同一逻辑时间点（尤其有延迟复制或网络抖动时），就直接导出从库数据回滚到主库。结果是恢复了“旧”数据，掩盖了后续正确写入。务必交叉验证
Exec_Master_Log_Pos、
Seconds_Behind_Master和业务日志时间戳。
