MySQL多级级联复制本质是A→B→C链式relay，B必须开启log_slave_updates=ON、server_id全局唯一、binlog_format=ROW；延迟累加，B为单点瓶颈；GTID模式下需严格备份gtid_purged并使用MASTER_AUTO_POSITION=1。
MySQL 多级级联复制本质是链式 relay，不是“一主多从”的变体
MySQL 本身不提供原生的「多级级联复制」开关或专用命令，所谓 A→B→C 架构，就是让 B 同时扮演 slave（拉取 A 的 binlog）和 master（向 C 提供 binlog），关键在 B 节点必须开启 log_slave_updates。没开这个，B 执行完 relay log 后就丢弃，C 连不到任何可复制的 binlog。
-
log_slave_updates=ON是强制要求，否则 C 永远收不到 A 的变更 - B 的
server_id必须全局唯一，且不能和 A、C 冲突 - A 和 C 之间无需网络互通，只要 A↔B、B↔C 可达即可
- 复制延迟会逐级累加：A→B 延迟 + B→C 延迟，B 成为单点瓶颈
配置 B 节点：开启中继日志转发的三步操作
很多线上故障源于 B 节点重启后复制中断，根本原因是 log_slave_updates 没写进配置文件，只临时 SET 过。必须固化到 my.cnf 并重启 mysqld。
- 编辑
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，在[mysqld]下添加：log_slave_updates = ON<br>binlog_format = ROW
-
binlog_format = ROW强烈建议，避免语句级复制在 B 上执行失败导致 C 复制中断 - 重启前确认 B 已完成对 A 的初始同步（
Seconds_Behind_Master = 0），否则重启后可能从错误位置开始 relay
检查 C 是否真的在复制 A 的数据：别只看 SHOW SLAVE STATUS
SHOW SLAVE STATUS\G 显示 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 只说明 C 连上了 B、SQL 线程在跑，不代表它同步的是 A 的原始变更。常见误判场景：
- C 的
Master_Host指向 B，但 B 的 binlog 里没有 A 的事件（log_slave_updates关闭）→ C 实际在空转 - 用
mysqlbinlog在 C 上查其 relay log：mysqlbinlog /var/lib/mysql/mysql-relay-bin.000001 | head -20，看 event 的server_id是不是 A 的 - 在 A 上执行
INSERT INTO test.t1 VALUES (now());，等几秒后查 C 的t1，再查 B 的show master status和 C 的Relay_Master_Log_File是否匹配
级联复制下 GTID 模式要格外小心
如果 A/B/C 全部启用了 gtid_mode=ON，B 的 log_slave_updates 开启后，C 会收到带 A 的 server_uuid 的 GTID，这没问题；但若中途 B 故障重建，用备份恢复时没保留 gtid_purged，C 就会报错 ERROR 1236 (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.
- 备份 B 时必须包含
gtid_purged值（SHOW GLOBAL VARIABLES LIKE 'gtid_purged';） - C 的
CHANGE MASTER TO必须用MASTER_AUTO_POSITION = 1，不能混用MASTER_LOG_FILE+MASTER_LOG_POS - GTID 模式下无法跳过某条事务（
SET GLOBAL sql_slave_skip_counter = 1无效），出错只能靠gtid_executed修补
SHOW PROCESSLIST 里 B 的 Binlog Dump 线程是否长期 Sleep，比盯着 Seconds_Behind_Master 更早暴露问题。 
