中间层从库B必须开启log-slave-updates，否则无法将A的变更转发给C，导致C报错或主从失效；该参数需在my.cnf中配置并重启生效，且影响B的I/O性能与延迟。
为什么中间层从库必须开启 log-slave-updates
级联复制（A → B → C）中，若中间层从库 B 不写自己的 binlog，它就无法把从 A 接收的变更再转发给下游 C。此时 C 会直接报错 Could not find first log file name in binary log index file 或始终停留在空主从状态——因为 B 根本没生成可被 C 读取的 binlog 事件。
这不是可选项，是级联链路成立的前提。MySQL 默认关闭该参数，上线前必须显式启用。
- 必须在 B 的
my.cnf中配置：log-slave-updates = ON，然后重启 mysqld（仅SET GLOBAL不生效） - 确认生效：登录 B 执行
SHOW VARIABLES LIKE 'log_slave_updates';，返回ON - 开启后，B 的 binlog 会包含所有从 A 应用过来的语句（ROW 格式下是解析后的行事件），C 才能正常拉取
开启 log-slave-updates 后延迟反而升高？查这三处
加了这个参数，B 的写入压力明显变大：不仅要执行 SQL，还要序列化、刷盘 binlog，还可能触发额外的 fsync。延迟跳升往往不是参数本身的问题，而是暴露了原本被掩盖的瓶颈。
-
sync_binlog = 1+innodb_flush_log_at_trx_commit = 1在 B 上同时开启，会导致每个事务强制刷盘两次（binlog & redo），I/O 成为瓶颈；建议 B 设为sync_binlog = 1000（或 0），保留数据一致性底线即可 - B 的磁盘类型是否为机械盘或低 IOPS 云盘？
SHOW SLAVE STATUS\G中Seconds_Behind_Master持续增长，且Read_Master_Log_Pos和Exec_Master_Log_Pos差值稳定扩大，大概率是 I/O 跟不上 - B 是否启用了
binlog_format = STATEMENT？若上游 A 有大量非确定性函数（NOW()、UUID()、USER()），B 写 binlog 时需做额外处理，也拖慢速度；统一用ROW更稳妥
如何验证 B 的 binlog 确实被 C 正确消费
不能只看 Seconds_Behind_Master 是 0，要确认 C 拉的是 B 当前正在写的那个 binlog 文件，且位置连续推进。
- 在 B 上执行：
SHOW MASTER STATUS;记下File和Position - 在 C 上执行：
SHOW SLAVE STATUS\G，核对Master_Host是 B 的地址，并检查Relay_Master_Log_File是否等于 B 的File，Exec_Master_Log_Pos是否接近 B 的Position - 如果
Relay_Master_Log_File是旧文件（如mysql-bin.000005），而 B 当前已是000008，说明 C 的 IO 线程卡住，需查Last_IO_Error
级联架构下，B 的硬件和配置容易被低估
很多人把 B 当成“透明中转”，按最低配部署，结果它成了整条链路的木桶短板。B 不仅要承担读流量，还要完整重放 A 的所有写负载，且多了一层 binlog 写入开销。
- B 的磁盘 IOPS 至少应 ≥ A 的 1.5 倍，推荐 NVMe SSD；避免和 A 共用同一块物理盘
- B 的
innodb_buffer_pool_size不能照搬 A——若 B 承担部分业务查询，缓存压力更大，需预留更多空间 - 禁用 B 的
query_cache_type（已废弃）或performance_schema（除非调试需要），减少不必要的内存与 CPU 开销
真正难的不是打开 log-slave-updates，而是让 B 在高吞吐下保持 binlog 生成与应用的平衡。很多延迟问题，追到最后都是 B 的磁盘或 buffer 配置没跟上实际负载。
