mysql如何监控主从复制的流量消耗_mysql网络带宽监控

最可靠方式是抓取主库到从库的tcp流量，如用tcpdump或iftop；binlog磁盘体积不等于复制带宽，因存在过滤、压缩、重传等差异；带宽异常升高往往反映复制链路问题而非业务增长。

怎么看主从复制实际用了多少带宽

mysql 主从复制本身不直接暴露“每秒传输多少 KB”的指标，SHOW SLAVE STATUS 里只有 Seconds_Behind_Master 和 IO/SQL 线程状态，没法换算成带宽。真实带宽消耗得从网络层反推——不是看 MySQL，是看它用的 TCP 连接。

最可靠的方式是抓取主库上发往从库 IP:port 的流量。比如主库 IP 是 10.0.1.10，从库连的是 3306，那就盯这个连接：

sudo tcpdump -i any -w replication.pcap host 10.0.1.10 and port 3306 and dst 10.0.1.20

注意：dst 10.0.1.20 要换成你从库的真实 IP；如果主从走的是非标端口（比如 3307），记得改端口号。

• 别在生产高峰长期跑 tcpdump，文件增长快，磁盘和 CPU 都吃紧
• linux 上可用 iftop -P 3306 -f "host 10.0.1.20" 快速看实时速率，更轻量
• 云环境（如阿里云 ECS）可直接看「云监控」里的「外网/内网出方向流量」，筛选源 IP + 目标 IP 即可

binlog 文件大小 ≠ 复制带宽消耗

有人用 du -sh /var/lib/mysql/mysql-bin.* 算日志体积，再除以时间，当成带宽——这会严重高估。因为 binlog 是全量写入磁盘的，但复制只传其中一部分：比如 GTID 过滤、replicate-do-db 设置会让从库跳过某些库；主库上大量 INSERT ... select 或大事务产生的临时日志，在复制时可能被压缩或合并；还有半同步开启时重传、网络丢包重发，这些都让“发送字节数”和“binlog 文件体积”不一致。

• SHOW BINARY LOGS 显示的是磁盘占用，不是网络发出量
• 如果开了 binlog_row_image=MINIMAL，UPDATE 只传变化列，比 FULL 模式省一半以上带宽
• 主库 max_allowed_packet 设太小会导致大事务被拆成多个包，增加 TCP 包头开销，反而推高带宽

从库拉取慢导致带宽“脉冲式”堆积

当从库 SQL 线程卡住（比如遇到锁等待、大 DDL、磁盘 I/O 延迟），IO 线程仍持续从主库读 binlog 并缓存在 relay_log 里。这时主库出口带宽不会降，反而可能升高——因为从库会不断重连、重请求缺失事件，甚至触发 CHANGE MASTER TO ... RELAY_LOG_FILE 手动跳位点，引发重复拉取。

查这个现象的关键指标是：

• 主库 SHOW PROCESSLIST 里有没有多个 Binlog Dump 线程连同一个从库（说明频繁断连重连）
• 从库 Seconds_Behind_Master 持续上涨，同时 Relay_Log_Space 不断增大
• 主库 netstat -an | grep :3306 | grep ESTABLISHED | wc -l 突然变多

这时候带宽峰值未必反映业务压力，而是复制链路健康度告警。

想长期监控，别自己解析 tcpdump

手动抓包只能应急。真要长期看，优先用系统级工具聚合统计，而不是进 MySQL 解析 binlog：

• 用 ss -i 查单个连接的 rcv_ssthresh/cwnd，能看出 TCP 拥塞情况（间接影响有效带宽）
• prometheus + mysqld_exporter 只能报 mysql_slave_status_seconds_behind_master，不提供带宽，得配 node_exporter 的 node_network_transmit_bytes_total{device="eth0", instance="master-ip"}，再加 label 过滤目标从库 IP
• 如果主从走专线或 VPC 内网，交换机镜像端口 + ntopng 是最准的，但运维成本高

真正难的从来不是“怎么拿到数字”，而是区分清楚：这个带宽是业务写入驱动的，还是复制机制缺陷导致的无效重传——后者修好了，带宽自然下来，不用扩容网络。