drop table导致从库sql线程中断，因从库找不到表报错1051；须先确认表是否真被主库删除、从库有无残留数据或依赖，再选择gtid或binlog位置方式安全跳过，禁用slave_skip_errors=1051。
直接跳过错误无法修复 Drop Table 引发的同步中断，必须先确认该表是否真的已被主库删除、从库是否还残留数据或触发器依赖——否则 sql_slave_skip_counter 会掩盖更严重的不一致。
为什么 DROP TABLE 会让从库 SQL 线程卡住
主库执行 DROP TABLE t1 后，该语句被写入 binlog；从库重放时若发现表不存在（比如之前已手动删过、或备份恢复时漏了），就会报错 ERROR 1051 (42S02): Unknown table 'db.t1'，导致 Slave_SQL_Running: No。这不是权限或网络问题，而是语句执行层面的“找不到对象”。
- 常见错误日志片段：
Could not execute Drop_table event on table db.t1; Error_code: 1051 - GTID 模式下还会额外报
Could not execute command on empty relay log，因为 GTID 要求严格按事务顺序应用 - 注意：如果从库上该表仍存在但结构不一致（比如有额外字段），
DROP不会失败，但后续CREATE或INSERT可能出错——这属于另一类问题
先查清状态再决定跳还是重建
不要一看到 Slave_SQL_Running: No 就立刻跳过。先确认三件事：
- 在从库执行
SHOW CREATE TABLE db.t1—— 如果返回Table 'db.t1' doesn't exist，说明表确实没了，可以安全跳过这条DROP - 检查主库 binlog 中该语句上下文：
mysqlbinlog --base64-output=DECODE-ROWS -v master-bin.0000xx | grep -A5 -B5 "DROP TABLE.*t1"，确认它不是某个大事务中的一部分（比如DROP前还有INSERT/UPDATE） - 运行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator，看LAST_ERROR_MESSAGE是否明确指向DROP TABLE，排除其他并发错误干扰
跳过 DROP TABLE 的两种安全方式
仅当确认该 DROP 是孤立操作、且从库无需保留该表时使用。优先选 GTID 方式（MySQL 5.7 默认启用）：
- GTID 模式下（推荐）：
STOP SLAVE; SET GTID_NEXT='xxx-xxx-xxx:nnn'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;，其中xxx:nnn是出错事务的 GTID，可从show slave status\G的Retrieved_Gtid_Set和Executed_Gtid_Set差集推断 - 传统 binlog 位置方式（兼容性更强）：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;—— 注意这跳的是“下一个事件”，不是“当前事件”，所以要先STOP再设，否则可能跳错 - ⚠️ 禁止在
my.cnf里配slave_skip_errors = 1051：它会静默跳过所有DROP错误，包括你没意识到的其它表，极易引发隐性数据偏差
比跳过更稳的做法：用 xtrabackup 重建从库
如果从库已多次跳过、或你不确定表依赖关系（比如有视图、存储过程引用 t1），重建是最干净的解法。关键点不在备份本身，而在 --slave-info 和后续配置还原：
- 主库执行备份时必须带
--slave-info参数，否则从库无法自动获取CHANGE MASTER TO所需的 binlog 位置 - 恢复后，从库启动前务必检查
/var/lib/mysql/xtrabackup_slave_info文件内容，它是一条完整的CHANGE MASTER TO语句，直接执行即可（别手敲） - 特别注意
server-id和auto.cnf：重建后从库的auto.cnf会被覆盖为新 UUID，但my.cnf里的server-id必须和原来不同，否则 IO 线程立即退出
最易被忽略的是：跳过 DROP TABLE 后，如果主库紧接着 CREATE TABLE t1 并插入数据，而从库因跳过导致缺失建表语句，后续所有对该表的操作都会失败。所以跳过只是临时止血，长期稳定仍要靠定期校验表存在性与结构一致性。
