延迟复制防误删仅在删完即发现且5分钟内响应时有效；需先STOP SLAVE SQL_THREAD再设MASTER_DELAY，监控须同时看Seconds_Behind_Master和SQL_Remaining_Delay，GTID模式下禁用sql_slave_skip_counter，必须启用read_only和super_read_only。
能防，但只在“删完立刻发现+5分钟内响应”这个窄窗口里有效；它不是自动拦截器，而是给你留出手动抢救时间的缓冲带。
STOP SLAVE 后再改 MASTER_DELAY，否则报错 ERROR 3085
MySQL 要求必须先停掉 SQL 线程，才能设置 MASTER_DELAY。直接执行 CHANGE MASTER TO MASTER_DELAY = 3600 会触发错误：
ERROR 3085 (HY000): This operation cannot be performed with a running slave sql thread
正确顺序是：
-
STOP SLAVE SQL_THREAD;（只停 SQL，保留 IO 继续收 binlog） CHANGE MASTER TO MASTER_DELAY = 3600;START SLAVE SQL_THREAD;
注意：CHANGE MASTER TO 会清空当前复制位点（Relay_Master_Log_File 和 Exec_Master_Log_Pos），所以如果从库已运行一段时间，务必先用 SHOW SLAVE STATUS\G 记下 Master_Log_File 和 Read_Master_Log_Pos，并在 CHANGE MASTER TO 中显式补全，否则可能从 binlog 开头重放。
延迟 ≠ 固定滞后 N 秒：看 SQL_Remaining_Delay，别只盯 Seconds_Behind_Master
Seconds_Behind_Master 显示的是从库当前落后主库的总秒数，但它不等于你设的 MASTER_DELAY。真正反映“是否还在延迟等待中”的字段是：
-
SQL_Delay：配置值，比如 3600 -
SQL_Remaining_Delay：倒计时剩余秒数，仅当 SQL 线程正卡在延迟队列里时非 NULL
常见误判场景：
- 大事务正在执行（如长 UPDATE 或 DDL），
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（gtid_mode = ON），SET GLOBAL sql_slave_skip_counter = 1 会破坏 GTID 集合一致性，绝对禁用。
正确做法是手动注入空事务覆盖误操作 GTID：
- 从主库
mysqlbinlog或从库SHOW MASTER STATUS+Executed_Gtid_Set推断出误删语句对应的 GTID（如uuid:1234） - 在从库执行：
STOP SLAVE; SET GTID_NEXT = 'uuid:1234'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC'; START SLAVE;
这个过程无法完全脚本化，依赖 DBA 对 GTID 集合的即时解读——这也是最容易被忽略、最易出错的一环。
read_only=1 和 super_read_only=1 必须开，否则延迟形同虚设
延迟从库如果允许写入，DBA 登上去随手一个 DROP TABLE，就直接绕过所有防护。
必须确认两件事：
-
read_only = 1已在 my.cnf 中配置并生效 -
super_read_only = 1同时启用（MySQL 5.7.8+），否则拥有SUPER权限的用户仍可写
验证命令：SELECT @@read_only, @@super_read_only; 两个都得是 1。任何一项为 0，延迟从库就不具备“防人为误删”的基本前提。
真正起作用的从来不是那个 MASTER_DELAY = 3600 的数字，而是你有没有在误删后 3 分钟内停下 SQL 线程、有没有提前配好 GTID 跳过流程、以及有没有把 super_read_only 的开关拧死——这些细节，比参数本身更决定生死。
