中继节点比普通从库更容易卡住，因其需同时接收主库binlog并转发给下游，I/O和SQL线程压力超1.5倍；根本原因是角色叠加导致磁盘I/O、CPU及网络资源争用，尤其relay_log与binlog共盘时sync_relay_log=1强制刷盘会显著放大延迟。
中继节点为什么比普通从库更容易卡住
中继节点（Relay Slave）本身不对外提供读服务，但要同时承担「接收主库binlog」和「转发给下游从库」两件事，I/O和SQL线程压力是普通从库的1.5倍以上。常见现象包括：Seconds_Behind_Master持续增长、Relay_Log_Space暴涨、SHOW PROCESSLIST里出现大量Waiting for master to send event或Reading event from the relay log状态。
根本原因不是配置太低，而是角色叠加导致资源争用：同一块磁盘既要写relay log，又要读relay log再发给下游；同一组CPU要调度I/O线程、SQL线程、还有额外的dump线程（模拟主库向下游发送binlog）。
- 磁盘I/O成为首要瓶颈，尤其当relay log和binlog共用同一块SATA盘时
-
sync_relay_log = 1会强制每次写都刷盘，放大延迟 - 中继节点默认未启用并行复制，所有事务在SQL线程串行回放，下游延迟被逐级放大
必须改的三个关键配置项
中继节点不是“加强版从库”，它需要按“轻量主库+重负载从库”双重身份调优。以下三项不改，其他优化基本无效：
-
relay_log_info_repository = TABLE：避免文件型元数据锁竞争，提升崩溃恢复速度 -
slave_parallel_type = LOGICAL_CLOCK+slave_parallel_workers = 4：开启并行回放，否则大事务一来就卡死整条链路 -
sync_relay_log = 10000：牺牲极小一致性风险（最多丢失1万次写），换取relay log写入吞吐翻倍
注意：slave_preserve_commit_order = ON必须配合LOGICAL_CLOCK启用，否则并行回放可能破坏GTID顺序，下游从库报ER_GTID_EXECUTED_RANGE_EXCEEDS_RELAY_LOG错误。
磁盘与网络隔离是硬性要求
中继节点的I/O路径必须物理隔离，不能靠LVM或目录软链接糊弄。典型错误是把relay_log、binlog、datadir全放在同一块NVMe盘上——看起来快，实则随机读写互相干扰。
-
relay_log和binlog必须分盘：前者高频小块写+顺序读，后者高频追加写，混在一起会导致IOPS抖动 - 如果用SSD，建议
relay_log走一块专用盘，binlog走另一块，datadir单独挂载第三块（哪怕只是分区） - 网络层面禁用
tcp_nodelay = OFF（即启用Nagle算法），否则小包堆积导致dump线程发包延迟，下游感知为“主库没发新日志”
验证是否生效：iostat -x 1观察各盘的%util和await，若某块盘%util > 90%且await > 20ms，说明已成瓶颈。
如何避免中继节点变成单点故障源
中继节点一旦宕机或延迟过高，整条级联链路都会雪崩。除了硬件冗余，必须做两件事：
- 在中继节点上启用
relay_log_recovery = ON：崩溃重启后自动跳过损坏relay log段，不依赖人工CHANGE MASTER TO修复 - 下游从库的
MASTER_DELAY不要设为0，至少设60秒：给中继节点留出故障发现和切换窗口，避免主库误切后下游直接同步到半截事务 - 监控脚本必须检查
Seconds_Behind_Master和Seconds_Behind_Master_on_Relay（需自行计算：用SHOW SLAVE STATUS里的Read_Master_Log_Pos和Exec_Master_Log_Pos差值反推）
最容易被忽略的是：中继节点的max_connections要按“自身连接数+下游从库连接数”总和预估，否则dump线程会因无法获取连接而静默失败，现象是下游从库Slave_IO_Running: No且Last_IO_Error为空。
