如何优化MySQL主从复制网络带宽占用

slave_compressed_protocol常无效，因需主库≥5.7.17、从库重启IO线程且主库CPU不饱和；真正压主库上行带宽须优化binlog内容：设binlog_row_image=MINIMAL、log_slave_updates=OFF、binlog_transaction_compression=ON，并可用tc限速。

主库上行带宽打满，光开 slave_compressed_protocol 没用——它只压从库收包流量，不碰主库发包。

为什么 slave_compressed_protocol 经常没效果

这个参数不是“一设就生效”的开关，而是从库向主库发起连接时的一个协商请求。主库是否响应，取决于三个硬条件：

1. 主库 MySQL 版本必须 ≥ 5.7.17（旧版本直接忽略该请求）
2. 从库必须显式执行 STOP SLAVE IO_THREAD; SET GLOBAL slave_compressed_protocol = ON; START SLAVE IO_THREAD;，改完配置不重启 IO 线程等于没设
3. 主库 CPU 已满负荷时，压缩反而增加开销，可能被内核自动降级为明文传输

更关键的是：它只压缩 TCP payload 中的 binlog 流，不压缩心跳、ACK、协议头；对单条大事务（比如 UPDATE ... WHERE id IN (1,2,...,10000)）压缩率通常不到 30%，而内网万兆链路下基本无收益。

真正压主库上行带宽，得动 binlog 内容本身

主库网卡 tx 持续跑满，90% 的情况根源不在传输层，而在 binlog 日志体积过大。优先检查并调整：

1. binlog_row_image = MINIMAL：默认 FULL 会记录整行前后镜像；设为 MINIMAL 后，只记 WHERE 条件列（前镜像）和实际变更列（后镜像），宽表 UPDATE 场景下日志体积可降 60%+
2. log_slave_updates = OFF：如果从库不作级联中继，关掉它能避免主库多写一份 binlog，直接减半复制相关写入压力
3. binlog_transaction_compression = ON（MySQL 8.0.20+）：在主库侧压缩事务级 binlog 内容，比 slave_compressed_protocol 更早介入，对大事务效果更稳

注意：binlog_row_image 改完需确认业务逻辑不依赖非主键列判断变更（比如触发器或审计逻辑），否则可能漏同步。

系统层限速比应用层压缩更可控

当带宽瓶颈明确且无法扩容时，tc 是最直接的兜底手段——它不依赖 MySQL 版本，也不增加 CPU 开销：

1. 在主库执行：tc qdisc add dev eth0 root tbf rate 50mbit burst 32kbit latency 400ms（按实际带宽调整 rate）
2. 限速目标应略高于当前平均复制流量（可用 iftop -P 3306 实测），避免压死导致 IO 线程频繁重连
3. 搭配 slave_net_timeout = 60 和 master_retry_count = 86400，防止限速引发频繁断连重试

压缩只是锦上添花，真正的带宽控制权，始终在日志内容密度、网络拓扑和主库写入模式手里——一个全表 UPDATE 生成 200MB binlog，再好的压缩也扛不住持续发送。