iperf可直接验证主从网络吞吐是否足够：主库运行iperf -s -1，从库运行iperf -c 主库IP -p 5201 -t 60 -i 5；若千兆环境平均速率长期低于800Mbps或万兆低于7Gbps，即存在带宽瓶颈。
用 iperf 测主从网络吞吐是否够用
恢复慢常被归咎于“磁盘慢”或“CPU低”，但跨机房或跨可用区恢复时，真实瓶颈往往在网卡和中间链路。iperf 是最直接的验证手段，它绕过 MySQL 协议栈，只测裸带宽上限。
执行前确认：主库防火墙放行 5201 端口，从库能直连主库 IP；避免在业务高峰跑测试，否则会影响线上流量。
- 主库运行
iperf -s -1（作为服务端） - 从库运行
iperf -c 主库IP -p 5201 -t 60 -i 5（持续 60 秒，每 5 秒输出一次） - 若平均速率长期低于 800Mbps（千兆网卡理论值），说明存在带宽瓶颈；万兆环境低于 7Gbps 同理
看 mysqlbinlog 或 XtraBackup 流式恢复时的实际传输速率
逻辑备份（mysqldump）通过 TCP 发送 SQL 文本，物理备份（xtrabackup --stream）则流式发送二进制页。两者都受网络吞吐限制，但表现不同：
-
mysqldump | gzip | nc 主库IP 5201类型操作，可在接收端用pv查看实时流入速度：nc -l 5201 | pv -br > backup.sql.gz -
xtrabackup --stream=xbstream恢复时，加--throttle=100并观察iotop -p $(pgrep xtrabackup)中的 write rate，若远低于磁盘写入能力（如 SSD 写入 300MB/s，但实际只有 20MB/s），大概率是网络卡住了 - 注意：
slave_compressed_protocol=1只压缩复制流量，对备份恢复流无效；必须靠外部工具（gzip、zstd）或备份工具自身压缩参数
对比本地恢复与远程恢复耗时差值是否稳定大于 30%
这是最朴素但有效的判断法。同一份备份，在本地磁盘恢复耗时 T1，在相同机器上通过网络恢复耗时 T2，若 T2 / T1 ≥ 1.3，且多次重复结果一致，基本可锁定网络为瓶颈。
- 排除干扰：两次恢复都关闭
innodb_flush_log_at_trx_commit，禁用 binlog（SET sql_log_bin = 0），使用相同--use-memory参数 - 注意路径差异：本地恢复用
mysql < backup.sql，远程恢复建议用ssh user@backup-server "cat backup.sql" | mysql，避免 NFS/CIFS 等中间文件系统引入额外延迟 - 若差值波动极大（有时 1.2x，有时 5x），说明不是纯带宽问题，可能是网络抖动、TCP 重传或中间设备 QoS 限速
查 MySQL 错误日志里有没有 “timeout” 或 “broken pipe” 相关记录
这不是带宽瓶颈的直接证据，但它是网络不稳的强信号——而带宽不足常伴随高丢包、高重传，最终体现为连接中断。
- 搜索日志：
grep -i "timeout\|broken\|connection reset" /var/log/mysql/error.log - 重点看恢复过程中是否出现：
ERROR 2013 (HY000) at line XXX: Lost connection to MySQL server during query - 这类错误高频出现时，即使 iperf 测试看起来正常，也要怀疑是突发流量打满缓冲区导致 TCP 超时，需检查交换机 buffer、网卡 ring buffer 设置（
ethtool -g eth0）
