需开启log_bin、设置唯一server_id、启用log_slave_updates并重启mysql；级联时下游应连直连上游，gtid模式下须确保中间节点写入gtid且全局配置一致。
MySQL主从链路中，如何让从库再当主库（即开启binlog）
默认情况下，MySQL从库会关闭log_bin，导致它无法被下游节点作为主库使用。级联复制的前提是中间节点既接收上游的binlog，又生成自己的binlog供下游拉取。
必须显式启用log_bin并设置server_id——哪怕它当前是slave角色。否则CHANGE REPLICATION SOURCE TO在下游执行时会报错：ERROR 3021 (HY000): This server is not configured as a replication source。
-
log_bin必须开启，建议命名明确（如mysql-bin），避免和默认名冲突 -
server_id在整个拓扑中必须全局唯一，不能和上游或下游重复 - 推荐同时设
log_slave_updates=ON（否则它重放的事件不会写入自己的binlog） - 重启mysqld生效；仅
SET GLOBAL不持久，且部分变量（如log_bin）根本不可动态修改
配置第二级从库时，CHANGE REPLICATION SOURCE TO连的是谁
不是连最顶层主库，而是连它的直连上游——也就是第一级从库（此时已开启binlog并充当“中间主库”）。整个链路是线性转发：A → B → C，C的source是B，不是A。
容易错配成C直接连A，结果造成数据重复、GTID冲突或复制中断。尤其当DBA用脚本批量初始化从库却没区分层级时，这个问题高频出现。
- 确认B已启动复制（
SHOW REPLICA STATUS\G中Replica_IO_Running: Yes）、且Exec_Master_Log_Pos持续前进 - C上执行：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='B的IP', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=12345 - 务必用
SOURCE_LOG_FILE和SOURCE_LOG_POS（非GTID模式下），别依赖MASTER_AUTO_POSITION=1——除非全链路统一开启GTID且enforce_gtid_consistency=ON
GTID模式下做级联复制，为什么常卡在Retrieved_Gtid_Set为空
因为中间节点（B）没有开启log_slave_updates，导致它虽然应用了A的事务，但这些事务的GTID没写进自己的binlog，下游C就什么都拉不到。
这个现象在SHOW REPLICA STATUS\G里表现为Retrieved_Gtid_Set为空、Executed_Gtid_Set有值、Seconds_Behind_Master为NULL——不是延迟，是彻底断连。
- 检查B：
SELECT @@log_slave_updates;必须返回1 - 检查B的binlog是否真包含上游GTID：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep "GTID" - 如果B之前是传统复制模式，切换GTID需先停复制、重置、再启，不能热切
- 所有节点
gtid_mode=ON且enforce_gtid_consistency=ON缺一不可，否则START REPLICA会失败
级联深度超过3层后，延迟和故障传播变得特别敏感
每多一级，就多一次网络传输+SQL线程解析+磁盘刷写，延迟呈累加趋势。更麻烦的是，中间任意节点出问题（比如B宕机），C不仅停止同步，还可能因重试机制反复连接失败，触发告警风暴。
运维上最难处理的是“断点续传”：B恢复后，C的Source_Binary_Log_File和Source_Binary_Log_Pos很可能已失效，必须手动找B当前最新binlog位置重新配置。
- 监控不能只看
Seconds_Behind_Master，要额外采集每个节点的Read_Source_Log_Pos与Exec_Source_Log_Pos差值 - 避免无意义的深链（如A→B→C→D→E），4层以上建议改用分发架构（如引入Canal/Kafka中转）
- 中间节点建议关闭
innodb_flush_log_at_trx_commit=2和sync_binlog=0来降低IO压力（但需接受小概率数据丢失）
级联复制真正的复杂点不在配置命令本身，而在于每一层都既是消费者又是生产者——角色切换带来的状态一致性、日志生命周期管理和故障隔离，稍不注意就会变成黑盒延迟源。
