我们已经有超过6个月的主/从设置。复制从来就不是问题。如果主人失败，奴隶不会被用于“保险单”以外的任何其他事项。它唯一的活动就是每天凌晨2:30，奴隶停止，完成一次完整备份，然后重启奴隶。备份通常需要大约30分钟，奴隶会在10分钟内恢复。
奴隶是一个更强大的机器（24核v.s 8）我们只是考虑将它切换为主人并在即将到来的周末逆转复制。
昨天早上9点，奴隶开始落后。主人没有很大的负担。真正不寻常的是从站的负载平均值约为3，大约有2％的等待时间（在顶部显示）和大约1/10％的CPU利用率，但是从站没有赶上。它看起来几乎处于停滞状态。处理1秒复制日志大约需要10分钟（从实际时间减去秒数）。从IO线程跟上主机的bin日志，它只是爬行查询的sql线程。然而，正在处理查询，对从属状态进行监视会显示exec主日志pos的持续更新。
我们已经尝试停止slave io线程以查看它是否有用，它没有任何影响。就好像突然间每个查询都变得非常昂贵。
我们已经对底层raid进行了磁盘检查，系统或mysql日志中没有任何内容表明存在任何错误。我们重启了多次重启mysql，清除了系统缓存等等......
这是在生产系统上，该系统在一周内没有任何代码更改，并且在此事件之前没有异常的操作问题。
我们完全不知道为什么一个没有接近峰值负载的系统似乎无法跟上主人的原因。
我们还应该研究什么？我很乐意在这里发布系统统计数据等，如果它能帮助我们帮助我们确定什么是“错误的”。
答案 0 :(得分：0)
我检查过的最后一次，复制是单线程的，所以我希望你能找到一个让系统变得便秘的慢查询。我有一个客户端，其复制正常，但落后10M秒！ （糟糕）
在SHOW FULL PROCESSLIST中显示什么查询？它始终是相同的查询？如果是这样，也许该查询变得更加昂贵。尝试解释它（或变体，如果它是更新等）。
如果您没有立即看到它，请尝试启用慢速查询日志并查看您获得的内容。
答案 1 :(得分：0)
事实证明，一个inodb表已经变得相当大，并且插入其中变得越来越昂贵。我们将表格切换到主设备上的myisam（实际上是奴隶）和它抓住的奴隶。当把它转换成myisam的“alter table”降到奴隶时，它基本上变成了无操作。