Replica Lag

做的事：真实制造一次写入压力，一边高频轮询延迟指标

代码-- source: 400次真实独立的INSERT（各自单独提交） for i in 1..400: INSERT INTO shop.bigwrite (note) VALUES (REPEAT('y',190)); -- replica: 每秒查一次 SHOW REPLICA STATUS; -- 看 Seconds_Behind_Source

验证：写入进行中，延迟指标真实全程是0

实测 · 本机执行输出（每秒一次快照）

t=1s  secbehind=0  replica_rows=56
t=2s  secbehind=0  replica_rows=114
t=3s  secbehind=0  replica_rows=172
t=4s  secbehind=0  replica_rows=229
t=5s  secbehind=0  replica_rows=287
t=6s  secbehind=0  replica_rows=345
t=7s  secbehind=0  replica_rows=400   ← source此时也刚好写完400行

本以为400次真实独立的写入会真实让replica明显落后一截，结果Seconds_Behind_Source真实全程都是0，而且replica的行数几乎和source同步增长——两边在每一个整秒的采样点上都真实几乎打平。

结论：这次真实"没有延迟"，本身就是一个真实的发现

这次实验诚实的结论是：本文没能真实复现出复制延迟这个现象，原因也真实找到了——瓶颈根本不在replica的应用能力上，而在source这一侧400次mysql -e各自独立建连接、执行、断开的客户端开销上(每次约15-20毫秒)，这个开销本身就让source的写入速度被真实限制住了，replica单线程SQL应用一条不到200字节的简单INSERT，真实比这个客户端开销快得多，完全跟得上。真实要复现出复制延迟，通常需要的是：source上真实存在大事务(比如一条影响几十万行的UPDATE，SQL线程要单线程地把它整个应用完才能往下走)，或者replica的硬件真实明显弱于source，或者网络真实存在延迟——单纯"写得快"不等于"replica跟不上"，这两者不能划等号。下一篇的延迟复制(SOURCE_DELAY)会展示一种真实能稳定复现、可控的延迟场景，跟这里"意外没复现"的自然延迟形成对比。

分步演示：写入压力下，延迟指标真实的表现

每一步都是本文上面用真实写入压测跑出来的原始结果。

没能真实复现延迟，本身也是一个真实的结果

这一步新采样的时刻

本文用到的工具

本机真实的两节点复制实验环境，400次独立写入压力测试
Seconds_Behind_Source状态字段的真实高频轮询
没有验证：真实能稳定复现复制延迟的场景（大事务、慢硬件、网络延迟），本文只如实记录了这次没能自然复现的结果

下一篇 · MYSQL / INNODB 94

Row-Based Binlog