relay_log在MySQL主从复制链中不可跳过，B必须开启log_slave_updates才能将变更写入binlog供C同步，且需配置唯一server_id、一致binlog_format；GTID模式更可靠但要求全链路统一开启并启用enforce_gtid_consistency。
主从复制链中 relay_log 的角色不能被跳过
MySQL 主从复制链（比如 A→B→C）本质是「日志转发」，不是直接数据同步。中间节点 B 必须开启 log_slave_updates，否则它执行完 relay log 后不会把变更写入自己的 binlog，C 就收不到任何事件。
常见错误是只配了 CHANGE REPLICATION SOURCE TO，却漏掉这个关键参数，导致 C 一直报 Could not find first log file name in binary log index file 或始终停留在空闲状态。
-
log_slave_updates = ON必须写进 B 的my.cnf并重启，动态 SET 不生效 - B 的
server_id必须唯一，且不能和 A、C 冲突（否则复制线程拒绝启动） - B 的 binlog 格式（
binlog_format）要与 A 一致，否则可能在 C 上解析失败
多级复制下 GTID 模式比传统 file/pos 更可靠
用 GTID（gtid_mode = ON）配置 A→B→C 链路，能避免因手动找 pos、跳过事务引发的不一致。GTID 自动追踪每个事务的全局唯一标识，B 在转发时会保留原 source_uuid，C 可据此判断是否已执行过该事务。
但要注意：所有节点必须统一开启 GTID，且 enforce_gtid_consistency = ON，否则启动复制时报错 ERROR 3098 (HY000): The table does not comply with the requirements...。
- 初始化时用
mysqldump --set-gtid-purged=ON导出，否则从库可能缺失部分 GTID - 不要在 B 上执行
RESET SLAVE ALL后再START SLAVE，这会清空gtid_executed，导致 C 重复执行或跳过事务 - 检查链路是否完整：在 C 上执行
SELECT * FROM performance_schema.replication_connection_status\G，确认SOURCE_UUID是 A 的，不是 B 的（说明 GTID 正确透传）
级联复制中从库延迟会逐级放大
B 作为 A 的从库如果有 5 秒延迟，C 同步 B 时就至少滞后 10 秒——因为 C 的 relay log 是 B 执行完才生成的。这不是 bug，是链式结构的固有特性。
如果业务对延迟敏感，不能只看 C 的 Seconds_Behind_Master，得用 SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP(READ_WRITE_TIME)（需配合 performance_schema 表）算端到端真实延迟。
- 禁用 B 的
slave_parallel_workers可能反而降低延迟：多线程写 relay log + 单线程读取转发，容易卡在 relay log I/O - B 上启用
relay_log_recovery = ON，防止崩溃后 relay log 损坏导致 C 复制中断 - 监控重点应放在 B 的
Retrieved_Gtid_Set和Executed_Gtid_Set差值，而不是 C 的Seconds_Behind_Master
SHOW SLAVE STATUS\G -- 关键字段示例： -- Retrieved_Gtid_Set: aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-100 -- Executed_Gtid_Set: aaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-95 -- 表示 B 还没执行完从 A 拿到的最后 5 个事务
链路越长，单点故障影响越大；B 崩溃不仅让 C 断连，还会导致 A 的 binlog 被提前 purge（如果 expire_logs_days 设置不合理）。实际部署中，三级以上复制链几乎总是得搭配 Orchestrator 或 MHA 做自动拓扑修复，纯靠 MySQL 自身机制扛不住。
