级联复制中延迟会逐层叠加而非简单传递，因每级需独立完成IO拉取、relay log写入及SQL回放，导致C节点延迟可达B节点的2–5倍；GTID链断裂、网络跃点增加、中间节点read_only被绕过等均会引发隐性中断或数据不一致。
级联复制中 Relay Log 积压会层层放大延迟
级联复制（A → B → C）不是简单把延迟“传下去”，而是让每一级都叠加自己的处理耗时。B 节点既要拉取 A 的 binlog，又要写 relay log、再回放；C 节点同样要拉取 B 的 relay log（本质是 B 的 binlog），再写自己的 relay log、再回放。每层 IO + SQL 处理都引入独立延迟，且无法并行抵消。
常见表现：Seconds_Behind_Master 在 C 上可能比 B 高出 2–5 倍，即使 B 的延迟只有几秒；Relay_Master_Log_File 和 Exec_Master_Log_Pos 在 C 上明显落后于 B 的 Master_Log_File 和 Read_Master_Log_Pos，说明 B 的 relay log 还没被 C 完全拉完。
- B 节点磁盘 IO 差（relay log 写慢）→ C 的 IO 线程拉取变慢 → C 的
Read_Master_Log_Pos滞后 - B 节点 SQL 线程卡住（如大事务未完成）→ relay log 文件不滚动 → C 无法开始拉取新事件
- C 节点
slave_parallel_workers开了但Retrieved_Gtid_Set远小于 B 的Executed_Gtid_Set，说明根本没拿到足够事务来并行
GTID 传递链断裂导致从库跳过或重试
级联场景下，GTID 的生成和传播依赖每个节点正确设置 gtid_mode=ON、enforce_gtid_consistency=ON，且不能手动 SET GTID_NEXT。一旦 B 节点因异常重启、relay log 损坏或配置错误导致 Executed_Gtid_Set 不完整，C 就可能收到不连续的 GTID 流，触发 ERROR 1236 (HY000) 或自动跳过事务（slave_skip_errors 开启时），造成数据不一致与隐性延迟。
验证方法：在 C 上执行 SELECT @@global.gtid_executed;，对比 B 的 SELECT @@global.gtid_executed; —— 若 C 的 GTID 集合缺失中间段，说明 B 没有完整转发。
- B 节点
relay_log_recovery=OFF且异常宕机后重启，可能导致 relay log 截断，丢失部分 GTID - C 的
MASTER_AUTO_POSITION=1依赖 B 的 GTID，若 B 的gtid_purged被误清或未同步给 C，C 会报错无法连接 - 主库开启
binlog_transaction_dependency_tracking=WRITESET，但 B 是 5.7 版本（不支持 WRITESET 解析），转发到 C（8.0）时依赖信息丢失，C 并行复制退化为串行
网络跃点增加导致 IO 线程持续 lag
从 A 到 B 是一条网络路径，B 到 C 是另一条——这意味着两次 TCP 连接、两次 SSL 握手（若启用）、两次 binlog dump 协议交互。任何一跳出现丢包、RTT 波动或防火墙限速，都会让 IO 线程卡在 Waiting for master to send event 或 Connecting to master 状态。
典型现象：Slave_IO_Running: Yes，但 Seconds_Behind_Master 持续增长，且 Read_Master_Log_Pos 几乎不动；用 tcpdump -i any port 3306 在 C 上抓包，发现大量重传或零窗口通告。
- 跨机房部署时，B 和 C 不在同一内网，B→C 的带宽/延迟远差于 A→B
- B 节点 CPU 高导致 dump 线程响应慢，C 的 IO 线程超时重连，默认
slave_net_timeout=60，每次重连损失至少 1 秒 - 未启用
slave_compressed_protocol=ON，大事务 binlog event 传输体积翻倍，加剧网络瓶颈
从库 read_only 被绕过引发 GTID 冲突
级联链中任意中间节点（如 B）若意外关闭 read_only=1，又接受写入，就会产生本地 GTID 事务。这些事务不会发往 A，但会被 B 写入自己的 binlog 并传给 C。C 回放时遇到未知 GTID，直接报错 ERROR 1032 (HY000): Can't find record in 'xxx' 或 ERROR 2003 (HY000)，SQL 线程停止，延迟归零但实际已中断。
这类问题往往静默发生：B 的 SHOW SLAVE STATUS\G 仍显示正常，C 却长期卡在某个 GTID 无法前进。必须查 C 的 error log 才能定位。
- B 节点被运维误操作执行
SET GLOBAL read_only=0，随后有应用连上去写了脏数据 - B 的监控脚本定期检查
read_only，但没覆盖 MySQL 启动参数中的read_only=OFF配置项 - C 的
gtid_mode=ON但enforce_gtid_consistency=OFF，允许非 GTID 事务混入，进一步污染 GTID 序列
