必须先执行STOP SLAVE SQL_THREAD，再设置MASTER_DELAY，否则报错3085；CHANGE MASTER TO会清空位点，需显式补全MASTER_LOG_FILE和MASTER_LOG_POS；监控应重点关注SQL_Remaining_Delay而非Seconds_Behind_Master；GTID模式下严禁使用sql_slave_skip_counter。
STOP SLAVE SQL_THREAD 是设置 MASTER_DELAY 的前提
直接执行 CHANGE MASTER TO MASTER_DELAY = 3600 会报错 ERROR 3085 (HY000): This operation cannot be performed with a running slave sql thread。MySQL 要求必须先停掉 SQL 线程，IO 线程可以继续运行来接收 binlog——这样既能保留最新中继日志，又避免重放位置丢失。
正确操作顺序是：
STOP SLAVE SQL_THREAD;-
CHANGE MASTER TO MASTER_DELAY = 3600;（注意：这会清空当前Relay_Master_Log_File和Exec_Master_Log_Pos） START SLAVE SQL_THREAD;
如果从库已同步一段时间，务必在 CHANGE MASTER TO 中显式补全 MASTER_LOG_FILE 和 MASTER_LOG_POS，否则可能从 binlog 开头重放，导致数据重复或错乱。
监控必须同时看 SQL_Delay 和 SQL_Remaining_Delay
Seconds_Behind_Master 容易误导：它反映的是从库整体落后主库的秒数，但不等于你设的延迟值。真正表示“是否还在卡点等待”的字段是 SQL_Remaining_Delay —— 它只在 SQL 线程处于延迟等待状态时非 NULL，且是倒计时剩余秒数。
常见误判场景：
- 大事务正在执行（如长 UPDATE），
Seconds_Behind_Master飙升到上万，但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;（立即阻断那条 DROP/DELETE 的执行） -
SHOW SLAVE STATUS\G查Relay_Master_Log_File和Exec_Master_Log_Pos，定位误删语句前一个位点 - 用
mysqlbinlog解析对应 binlog 文件，跳过误删事件后重放，或直接从延迟从库导出表
别碰 sql_slave_skip_counter，尤其在 GTID 环境里，它不是快捷键，而是雷区。
延迟不是“固定滞后 N 秒”，而是“卡住 N 秒再执行”
MASTER_DELAY = 3600 不代表从库永远慢一小时。真实行为是：SQL 线程每次准备执行一个事件前，先检查距该事件在主库上的写入时间是否已满 3600 秒；未满就等待，满了才执行。
这意味着：
- 主库空闲时，
SQL_Remaining_Delay接近 3600，延迟稳定 - 主库突发大量小事务，从库能跟上 IO，但每个事件仍被卡满 3600 秒 → 延迟表现“精准”
- 主库有超大事务（如 ALTER TABLE），该事务在从库执行期间，
SQL_Remaining_Delay不更新，但Seconds_Behind_Master会持续上涨 → 这是设计使然，不是配置失败
最易忽略的一点：延迟复制只防“删完立刻发现”的窄窗口（比如 5 分钟内响应）。它不拦截、不预警、不自动回滚，只是一个被动缓冲带——DBA 必须在 SQL_Remaining_Delay 归零前完成 STOP、定位、导出动作，否则那条 DROP 就执行了。
