mysql复制的ec2实例之间的带宽异常

我正在两个AWS实例之间使用MySQL复制：m4.xlarge。 版本5.6.35

有时我会遇到复制延迟时间高的问题，增加的太多，超过主机xx，000秒。我发现从机上的io_线程无法赶上主数据库上的bin_日志大小

此时，主设备和从设备之间的带宽和字节传输非常低（以字节为单位）

但是当我将Slave的实例类型从m4.xlarge更改为t2.xlarge并向后更改时。主从之间的带宽立即增加（高达400kb/s）。保持master db，请勿触摸或更改。很快，复制延迟消失了。这很奇怪。 （iftop检查带宽）

你能告诉我这有什么问题吗？当我们更改实例类型时会发生什么？我们怎样才能发现根本原因呢

---

非常感谢。

似乎有人遇到了同样的问题

---

您是否尝试关闭同步日志？（sync_binlog=0）

我已经检查并监测到问题来自于我们的从数据库的

突发平衡不足。(). 

因为我们的从属数据库只有20GB的小存储空间，所以它只有默认的100 IOPS

IOPS = Volume size (in GB) * 3
Minimum for gp2 is 100 IOPS
Maximum for gp2 is 3000 IOPS

我将存储空间增加到50GB以获得150 IOPS，现在io_线程运行得更好

停止/启动实例也将突发平衡重置为100%，但这只是一个快速提示。如果EC2实例之间存在高延迟，则应在带宽旁边检查此指标。
注意：在延迟时间变高之前，主数据库上有大量提交/更新。是的，同步日志已关闭。此变量是在6个月前复制开始时设置的变量| name | Value |+-------------+----+| sync | u binlog | 0 |似乎适合为我联系aws支持人员。您是否尝试用另一个mySql版本复制此问题？谢谢。还没有，请使用我当前的5.6.35版本。顺便问一下，是否可以在主版本5.6.35和更高版本的从版本之间设置复制？我已经再次测试过，操作stop+start EC2实例在这种情况下工作。（这与更改实例类型无关）。它也不适用于重新启动。奇怪的是，停止&启动Ec2实例会改变Ec2实例背后的物理机器吗？我说的对吗？是的，大多数时候。它还释放与实例关联的EIP