MySQL延迟复制不是自动防误删开关，仅在误删后5分钟内手动干预才有效；必须先STOP SLAVE SQL_THREAD再设MASTER_DELAY，否则报ERROR 3085；监控须盯SQL_Remaining_Delay而非Seconds_Behind_Master；GTID模式下禁用sql_slave_skip_counter。
MASTER_DELAY 不是防误删的自动开关，它只在你发现误删后 5 分钟内手动干预才有效。配置错一步，比如没停 SQL 线程就改参数，MySQL 直接报 ERROR 3085，整个机制就失效。
必须先 STOP SLAVE SQL_THREAD 才能设 MASTER_DELAY
MySQL 强制要求：SQL 线程必须处于停止状态，才能执行 CHANGE MASTER TO MASTER_DELAY = N。这不是建议，是硬性校验。
- 直接运行
CHANGE MASTER TO MASTER_DELAY = 3600会立即失败，报错ERROR 3085 (HY000): This operation cannot be performed with a running slave sql thread - 正确顺序只有这一种：
STOP SLAVE SQL_THREAD;→CHANGE MASTER TO MASTER_DELAY = 3600;→START SLAVE SQL_THREAD; - 只停 SQL 线程（保留 IO 线程），是为了继续接收主库 binlog，避免位点断档；否则延迟生效期间可能丢日志
CHANGE MASTER TO 会清空位点，不补全就可能从头重放
执行 CHANGE MASTER TO（哪怕只改 MASTER_DELAY）会重置 Relay_Master_Log_File 和 Exec_Master_Log_Pos 为 NULL。如果从库已同步一段时间，这会导致 SQL 线程从主库 binlog 起始位置重放——轻则重复写入，重则主键冲突、数据错乱。
- 操作前务必先执行
SHOW SLAVE STATUS\G，记下Master_Log_File和Read_Master_Log_Pos - 在
CHANGE MASTER TO中显式补全：CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 1234, MASTER_DELAY = 3600; - 漏掉这两项，等于把复制“重置”了，不是加延迟，是开倒车
监控必须盯 SQL_Remaining_Delay，不是 Seconds_Behind_Master
Seconds_Behind_Master 是总滞后秒数，和你设的延迟值无关；真正表示“还在卡点等执行”的字段是 SQL_Remaining_Delay —— 它是倒计时，只在 SQL 线程主动等待时非 NULL。
- 大事务正在回放（如长 UPDATE），
Seconds_Behind_Master飙到 10000+，但SQL_Remaining_Delay仍是 3600 → 延迟正常生效 -
Seconds_Behind_Master = 0，但SQL_Remaining_Delay = 3590→ 实际仍在延迟中，只是当前没积压新事件 - 监控脚本若只查
Seconds_Behind_Master，会误判延迟已失效，错过抢救窗口
GTID 模式下严禁碰 sql_slave_skip_counter
启用了 gtid_mode = ON 后，SET GLOBAL sql_slave_skip_counter = 1 会破坏 GTID 集合一致性，导致复制中断甚至数据不一致。MySQL 明确禁止该操作。
- 误删发生后，正确做法是立刻
STOP SLAVE SQL_THREAD，然后用mysqlbinlog解析中继日志，定位误删前最后一个 GTID - 再用
START SLAVE UNTIL SQL_AFTER_GTIDS = 'xxx:yyy'精确回放到那个位置 - 导出数据后恢复主库，全程绕过
sql_slave_skip_counter
