EC2实例间MySQL复制带宽异常及高复制延迟问题求助

针对你遇到的情况——两台m4.xlarge实例部署的MySQL 5.6.35主从复制，seconds_behind_master飙到数万秒，从库IO线程跟不上主库binlog生成速度，但主从间带宽和传输量却极低，切换从库实例类型（m4<->t2.xlarge）后带宽又恢复——我结合AWS实例特性和MySQL 5.6的复制机制，给你梳理几个核心排查方向和解决方案：

一、先排查EC2实例的网络层面问题 #

1. 实例类型的网络性能差异与限制 #

m4.xlarge和t2.xlarge的网络配置本来就有区别：m4是固定性能实例，默认支持更高的网络带宽（最高10Gbps），而t2是突发性能实例，带宽是基准额度加突发。但你切换后带宽反而正常，说明原来的m4.xlarge可能存在网络性能被限制的情况：

• 去CloudWatch看实例的NetworkIn/NetworkOut峰值，对比实例的最大带宽限制，确认是不是真的没跑满；同时检查PacketLoss指标，如果有丢包，IO线程会不断重试，反而浪费时间拉取binlog。
• 检查是否开启了Enhanced Networking：m4系列默认支持，但如果没开，网络性能会大打折扣。登录实例执行ethtool -i eth0，看驱动是不是ena——如果是ixgbevf就是旧驱动，需要开启ENA（AWS控制台里实例的“网络”选项卡可以操作）。

2. 确认主从的网络位置 #

确保主从实例在同一个可用区（AZ），跨AZ的话网络延迟会高，但你的问题是带宽低，更可能是实例本身的网络问题；另外检查是否在同一个VPC，安全组和网络ACL有没有限制3306端口（MySQL复制默认端口）的流量。

二、调整MySQL IO线程的核心参数 #

MySQL 5.6的IO线程有几个参数直接影响binlog拉取效率，针对你的情况可以调整：

1. 缩短IO线程的超时时间 #

默认的slave_net_timeout是3600秒（1小时），如果主从之间有短暂的网络波动，IO线程会一直傻等不重试，导致binlog堆积。改成60秒试试：

SET GLOBAL slave_net_timeout = 60;

然后在my.cnf里永久配置：

slave_net_timeout = 60

2. 加快重连间隔 #

配合上面的超时时间，把master_connect_retry（IO线程重连主库的间隔）从默认60秒改成10秒，让IO线程更快恢复连接：

SET GLOBAL master_connect_retry = 10;

永久配置：

master_connect_retry = 10

3. 统一主从的max_allowed_packet #

如果主库的binlog事件大小超过从库的max_allowed_packet，IO线程会直接中断拉取，导致延迟。先检查两边的参数：

SHOW VARIABLES LIKE 'max_allowed_packet';

建议统一设置成128M（根据你的业务调整，别太小）：

max_allowed_packet = 128M

三、排查binlog的生成与传输效率 #

1. 检查主库的大事务 #

如果主库有大量大事务，会导致binlog里的事件体积过大，从库IO线程一次性拉取压力大，容易卡住。可以用mysqlbinlog查看binlog里的事务：

mysqlbinlog --verbose --base64-output=DECODE-ROWS mysql-bin.000001 | grep -A 10 "BEGIN" | grep -B 10 "COMMIT"

如果发现大事务，建议业务侧拆分，或者主库开启binlog_group_commit_sync_delay（MySQL 5.6支持），让主库攒一批事务再同步binlog，减少IO次数。

2. 清理从库的relay log #

如果从库的relay log没及时清理，会占用磁盘空间，甚至导致IO线程读取变慢。确保relay_log_purge=ON（默认是ON），并设置自动清理天数：

expire_logs_days = 7
relay_log_purge = ON

四、实例切换后恢复的可能原因 #

你切换实例类型后带宽正常，大概率是这两个原因：

• 原来的m4.xlarge实例所在的物理主机网络拥塞，切换后实例迁移到了网络更空闲的节点；
• 旧实例的网卡硬件存在隐性故障，新实例的网络硬件正常。

总结排查步骤 #

1. 先看CloudWatch的网络指标，确认丢包、带宽利用情况；
2. 检查EC2的Enhanced Networking是否开启；
3. 调整MySQL的IO线程参数；
4. 排查主库大事务和从库relay log清理情况；
5. 如果以上都没用，尝试重新搭建复制（用xtrabackup或mysqldump做全量备份，重新配置主从），避免旧复制链路的隐藏问题。

内容的提问来源于stack exchange，提问作者Khoa Tran