延迟复制

做的事：真实配置一个5秒的复制延迟

代码STOP REPLICA; CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 5; START REPLICA; -- source: INSERT INTO shop.orders (item, qty) VALUES ('honeydew', 8);

验证：真实的延迟时间，跟配置几乎分毫不差

实测 · 本机每秒轮询的真实结果

t=1s   honeydew_on_replica = 0
t=2s   honeydew_on_replica = 0
t=3s   honeydew_on_replica = 0
t=4s   honeydew_on_replica = 0
t=5s   honeydew_on_replica = 1   ← 真实精确在第5秒出现
t=6s   honeydew_on_replica = 1
t=7s   honeydew_on_replica = 1
t=8s   honeydew_on_replica = 1

前4次真实的查询都是0，第5次真实精确变成1——SOURCE_DELAY真实是IO线程正常实时接收binlog、写进relay log，但SQL线程真实被人为要求"故意等够N秒之后才应用"，这个延迟真实是可以精确控制的，不像上一篇的自然复制延迟那样受各种不可控因素影响。

结论：延迟复制真实是留给人为操作失误的一个后悔窗口

延迟复制真实最常见的用途是防御性容灾：如果生产环境真实发生了一次误删表、误更新全表这类灾难性的人为操作，一个正常同步的replica会真实在几秒内也执行同样的破坏操作，无法用来恢复；但一个真实配置了几小时延迟的replica，还没来得及重放这条破坏性语句，运维就有真实的时间窗口去STOP REPLICA把它定格在"灾难发生前"的状态，从这个延迟副本上真实找回数据。这不是备份的替代品(它依然是同一份数据的复制，source的物理损坏一样会通过复制影响到它，只是被推迟了)，而是"人为误操作"这一类特定风险的真实缓冲垫，通常会和真正的定期备份搭配使用。

分步演示：8次真实轮询，精确捕捉延迟的边界

每一步都是本文上面用真实的SOURCE_DELAY配置跑出来的原始结果。

从上一篇的意外零延迟，到这一篇的精确5秒

这一步新采样的时刻

本文用到的工具

本机真实的两节点复制实验环境，CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 5
延续上一篇《Replica Lag》里"没能自然复现延迟"的真实发现，用这个参数做出了可控对照

下一篇 · MYSQL / INNODB 99

多源复制