什么是延迟复制？

在从库设置固定延迟时间（如 1 小时），使其数据状态滞后主库指定窗口。非故障，而是刻意配置的保护机制。

配置方法

-- 登录从库
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_DELAY = 3600;  -- 单位：秒
mysql> START SLAVE;

-- 验证
mysql> SHOW SLAVE STATUS\G
# SQL_Delay: 3600
# SQL_Remaining_Delay: 当前剩余延迟秒数

三大核心应用场景

1. 误操作闪回（最实用）

开发/运维误执行 DROP TABLE、DELETE 无 WHERE、UPDATE 全表等破坏性操作：

• 延迟窗口内，从库数据仍完好。
• 停止延迟从库复制 → 导出受影响表/库 → 导入主库恢复。
• RTO（恢复时间目标）可控制在分钟级，远快于全量备份恢复。

2. 主从延迟压测与架构验证

• 模拟“从库延迟 1 小时”场景，验证读写分离中间件（Mycat/ProxySQL）路由逻辑、业务降级策略、监控告警触发。
• 无需人为制造负载或网络故障，一条命令即可复现。

3. 历史数据快照查询

• 业务需定期查看“N 小时/天前”的表状态（如对账、审计）。
• 延迟从库充当“只读时光机”，免去恢复备份再查询的繁琐。

关键监控指标

• SQL_Delay：配置的固定延迟秒数。
• SQL_Remaining_Delay：当前剩余等待秒数，0 表示正在追赶或已追平。
• Slave_SQL_Running_State：显示 Waiting until MASTER_DELAY seconds after master executed event 确认延迟生效。

注意事项与限制

• 仅 MySQL 5.6+ / MariaDB 10.0+ 支持。
• 延迟从库不适合作为高可用备选主库，故障切换会丢失延迟窗口内的数据。
• 主库 binlog_format=ROW 推荐，减少延迟复制时的冲突。
• 延迟期间 Relay Log 会堆积，需预留足够磁盘空间。

最佳实践架构

主库 (实时写入)
   │
   ├─→ 从库 A (实时同步，提供读服务)
   │
   └─→ 从库 B (延迟 1h，仅做闪回/审计/压测，不承担业务读流量)

延迟从库与实时从库共存，互不干扰，各司其职。