必须开启log_slave_updates，否则级联复制在B节点中断——C无法接收A的任何变更；因从库默认只执行relay log且不写入自身binlog，而C依赖读取B的binlog实现复制，未启用该参数则B的binlog为空或仅含本地写入，导致A的变更无法透传。
必须开启 log_slave_updates，否则 C 根本收不到 A 的任何变更——不是延迟高，是链路直接断掉。
为什么 log_slave_updates 是硬性前提
MySQL 从库默认只执行 relay log，执行完就丢弃，不会写入自己的 binlog。而 C 要复制，靠的是读 B 的 binlog（不是 relay log）。没开 log_slave_updates，B 的 binlog 里全是空的或只有本地写入，A 的变更完全不透传。
常见误判现象：SHOW REPLICA STATUS\G 显示 Slave_IO_Running: Yes，但 Retrieved_Gtid_Set 为空、Relay_Master_Log_File 指向空 binlog 文件，本质是 C 连上了一个“假主库”。
-
SET GLOBAL log_slave_updates = ON临时生效，但 B 重启后失效；必须写进配置文件并重启mysqld - 该参数仅对已启用
relay_log的实例（即已配置为 slave 角色）生效 - 开启后，B 的 binlog 里会出现
server_id来自 A 的 event，这是 C 正确识别源头事务的关键
B 节点必须同时满足三项配置才能当好中继主库
单独开 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）重复，否则复制线程拒绝启动；也不能为 0 或 1（旧版本兼容限制） -
binlog_format = ROW：强烈建议，避免语句级复制在 B 上因NOW()、UUID()、自增等导致执行失败，进而让 C 卡住
这三项都得写进 /etc/my.cnf 的 [mysqld] 段，然后 systemctl restart mysqld。
C 连接的是 B，不是 A —— 别配错 SOURCE_HOST
C 的复制源必须指向 B 的 IP 和端口，不是 A。配成 C 直连 A，会导致：
- GTID 冲突（尤其在全 GTID 模式下）
-
MASTER_LOG_FILE位置错乱，C 可能跳过已应用的事件 - 主键冲突（非幂等写入场景下，A→B→C 和 A→C 并行写同一张表）
实操易错点：
- 用脚本批量初始化从库，却忘了区分层级，统一填了最上层 A 的地址
- B 刚重启，
SHOW MASTER STATUS的Position还是 4（初始值），但 C 用这个位置去连，实际会跳过 B 已应用的 relay event - 确认 B 已稳定同步 A：
Seconds_Behind_Master = 0且Exec_Master_Log_Pos持续前进后再操作 C
验证 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());，几秒后查 C 的t1，再比对 B 的SHOW MASTER STATUS和 C 的Relay_Master_Log_File是否匹配 - 在 C 上查其 relay log：
mysqlbinlog /var/lib/mysql/mysql-relay-bin.000001 | head -20，看 event 的server_id是不是 A 的
GTID 模式下要格外小心：B 故障重建时若没保留 gtid_purged，C 启动复制会直接报错 ERROR 1236，因为 MASTER_AUTO_POSITION = 1 依赖完整的 GTID 集合上下文。
