log_slave_updates必须开启，否则B不写relay log到binlog导致B→C复制中断；server_id和server_uuid须全局唯一；GTID模式下C连接B需加GET_MASTER_PUBLIC_KEY=1；binlog_format必须为ROW。
log_slave_updates 必须开启，否则 B 不会写 relay log 到 binlog
这是级联复制最常卡住的地方：A → B 正常，但 B → C 始终没数据。根本原因是 log_slave_updates 默认是 OFF，B 作为从库只执行 SQL，不记录自己执行过的事件到自己的 binlog，C 就无从拉取。
实操建议：
- 在 B 的配置文件（
my.cnf）中显式设置：log_slave_updates = ON，然后重启 mysqld 或执行SET PERSIST log_slave_updates = ON（MySQL 8.0+） - 确认生效：登录 B 执行
SHOW VARIABLES LIKE 'log_slave_updates'，输出必须是ON - 注意：该参数动态开启后，已有的 relay log 不会自动补录到 binlog，只对后续同步事件生效
主从 UUID 和 server_id 不能重复，尤其 B 要避开 A 和 C
MySQL 5.6+ 用 GTID 复制时，靠 server_uuid 区分实例；即使不用 GTID，server_id 也必须全局唯一，否则 C 从 B 拉日志时可能被拒绝或跳过事件。
常见错误现象：
- C 报错：
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'—— 往往是 B 的 binlog 索引损坏或压根没生成，根源常是server_id冲突导致复制线程异常退出 - B 的
SHOW SLAVE STATUS\G中Seconds_Behind_Master为 NULL，且Slave_SQL_Running_State卡在 “Reading event from the relay log” —— 可能因 UUID 重复触发了内部规避逻辑
检查方式：三台机器分别执行 SELECT @@server_id, @@server_uuid，确保六个值两两不同。
GTID 模式下，B 向 C 复制必须用 CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1（仅限 MySQL 8.0.28+）
如果启用了 enforce_gtid_consistency = ON 且用的是 MySQL 8.0.28 以上版本，C 连接 B 时若未显式启用公钥交换，握手阶段就会失败，报错类似：ERROR 3092 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.
这不是日志被删了，而是认证环节卡住后，C 错误地认为 GTID gap 不可修复。
正确做法：
- 在 C 上执行：
CHANGE MASTER TO MASTER_HOST='B_ip', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1, GET_MASTER_PUBLIC_KEY=1 - 前提是 B 已开启
require_secure_transport = OFF或已配好 TLS；若强制 TLS，还需加MASTER_SSL=1等配套参数
binlog_format 必须为 ROW，STATEMENT 或 MIXED 在级联场景下极易出错
STATEMENT 格式下，B 执行一条 UPDATE t SET c = NOW()，写入自己 binlog 的仍是这条语句；C 回放时用的是自己的系统时间，导致数据不一致。MIXED 更隐蔽——MySQL 自动切换时行为难预测。
真实踩坑点：
- A 和 B 都设了
binlog_format = ROW，但 C 启动时读的是旧配置，实际运行中仍是 STATEMENT，结果 C 的数据逐渐漂移 - 用
mysqldump --set-gtid-purged=OFF初始化 C 时，若 dump 文件里含SET STATEMENT临时改格式的语句，可能污染 C 的会话级 binlog_format
建议统一在所有节点的 my.cnf 中硬编码：binlog_format = ROW，并用 SELECT @@binlog_format 逐台确认。
级联链越长，中间节点的 binlog 写入可靠性越关键——它既是下游的源，又是上游的消费者，任何一个环节漏掉、写错、格式不兼容，下游就断在那儿，而且错误表现常常不直接指向根因。
