必须开启log_slave_updates，否则级联复制在b节点中断——c无法接收a的任何变更；因从库默认只执行relay log且不写入自身binlog，而c依赖读取b的binlog实现复制，未启用该参数则b的binlog为空或仅含本地写入，导致a的变更无法透传。
必须开启 log_slave_updates，否则级联复制在B节点就断了——C根本收不到A的任何变更，不是延迟高，是压根没数据。
为什么 log_slave_updates 是硬性前提
MySQL从库默认只执行 relay log，执行完就丢弃，不会写进自己的 binlog。而C要复制，靠的是读B的 binlog（不是relay log）。没开 log_slave_updates，B的binlog里全是空的或只有本地写入，A的变更完全不透传。
- 现象：C执行
SHOW REPLICA STATUS\G显示Slave_IO_Running: Yes，但Retrieved_Gtid_Set为空、Relay_Master_Log_File始终是空字符串 - 本质：B没转发，C连上的是个“假主库”
- 注意：
SET GLOBAL log_slave_updates = ON临时生效，但B重启后失效；必须写进配置文件并重启mysqld
配置B节点时，log_slave_updates 要和哪些参数一起开
单独开 log_slave_updates 不够，B必须同时满足三个条件才能当好“中继主库”：
-
log_bin = mysql-bin（或任意合法名）：B必须有 binlog，否则C连不上——报错ERROR 3021 (HY000): This server is not configured as a replication source -
server_id = 2（全局唯一）：不能和A（比如1）、C（比如3）重复，否则复制线程拒绝启动 -
binlog_format = ROW：强烈建议，避免语句级复制（STATEMENT）在B上因函数、时间戳、自增等导致执行失败，进而让C卡住
这三项都得写进 /etc/my.cnf 的 [mysqld] 段，然后 systemctl restart mysqld。
验证B是否真的在转发A的变更
别只信 SHOW REPLICA STATUS 里的 Yes，得看binlog内容本身：
- 在B上执行：
mysqlbinlog /var/lib/mysql/mysql-bin.000001 | head -30，确认输出里有来自A的server_id（比如server_id: 1），而不是全是server_id: 2 - 在A上插入测试数据：
INSERT INTO test.t1 VALUES (NOW());，几秒后查B的SHOW MASTER STATUS，看Position是否前进；再查C的Relay_Master_Log_File和Exec_Master_Log_Pos，应与B当前位置一致 - GTID模式下更关键：在C上执行
SELECT * FROM performance_schema.replication_connection_status\G，检查SOURCE_UUID字段是否等于A的server_uuid——这才是真正透传，不是B冒充
常见踩坑点：重启B后复制中断
线上高频故障：B节点维护重启后，C同步停滞。根本原因往往是：
-
log_slave_updates只用SET GLOBAL临时打开过，没写进my.cnf - B重启前没等
Seconds_Behind_Master = 0就直接重启，导致relay log未完全应用，重启后从旧位点重放，可能跳过事务或重复写入 - C连接B时用了
MASTER_AUTO_POSITION = 1，但B恢复时没保留gtid_purged，C启动时报ERROR 1236
最稳妥做法：B配置文件里固化所有参数，重启前先 STOP SLAVE 等同步追平，再重启；C初始化务必用 mysqldump --set-gtid-purged=ON 导出。
