主从复制中断后，需先通过show slave status\g分析错误类型；若为sbr且可接受数据不一致，可用set global sql_slave_skip_counter=1跳过；rbr则须解析binlog手工处理；跳过前必须备份；主库误删可从从库导出恢复；从库损坏应重建而非修复。
主从复制中断后，如何安全跳过错误继续同步
主从复制因 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 和业务日志时间戳。 
