我正在运行一个由 4 台服务器组成的 MySql 主-主集群。（2 台服务器版本 5.1，2 台服务器版本 5.5）
当检查从属状态时，我看到seconds_behind_master为0，半秒后我看到它跳转到2000，依此类推。
这可能是什么？我该如何调试它？
复制拓扑：1 -> 2 -> 3 -> 4 -> 1
更新
看起来服务器 3 的 SBM 为 0，而其他服务器的 SBM 却上下波动。这有帮助吗？
更新2 问题似乎出在服务器 1 上。在服务器 4 上创建测试表时，检查服务器 1 中的中继日志显示创建语句已立即复制到服务器 1 中的中继日志中，但未创建表。看起来服务器正在忙于执行某项操作，服务器获取语句和执行语句之间存在巨大的延迟。
更新 3 同样的事情也发生在服务器 4 上。
更新 4 好的，我找到了问题所在。服务器 1、2 和 4 的复制线程中卡住了“使查询缓存条目（表）无效”的问题。禁用缓存后，服务器 4 恢复正常，但服务器 1 和 2 仍然遇到此问题。
这看起来像一个常见的错误： http://bugs.mysql.com/bug.php?id=60696
如果有人知道如何修复它，我会很高兴听到
答案1
mysql 的 seconds_behind_master 值有一个缺陷：它只考虑相对于一个上游跳的位置。最简单的演示方法是使用稍微简单的复制拓扑：
服务器1->服务器2->服务器3
如果 server2 落后，并且正在处理一些长时间运行的查询，则将发生以下情况，假设 00:00 为起点：
00:00：一切正常
00:01：server1 将两个 10 分钟的查询写入 binlog，任何地方均无复制延迟
00:02：server2 开始处理查询一。server2 的复制延迟开始增加，server3 的复制延迟保持为零
10:02：server2 完成查询一，开始处理查询二。server2 的复制延迟仍在增加。server3 的复制延迟突然跳跃到 10 分钟。20
:02：服务器 2 完成查询 2，复制延迟再次为零。服务器 3 将完成查询 3，复制延迟跳回零，然后在处理下一个查询时回到 10。
因此，跳跃行为是由于未使用全局时间戳来表示复制延迟，而只是使用复制链中最后一个“跳跃”后面的延迟而引起的。我们发现这非常烦人，现在使用 MySQL 的事件调度程序每秒更新每个主服务器上的计时器表，因此我们实际上可以看到来自全局主服务器（在非环拓扑中）的实际延迟或来自环中任何对等点的延迟。
答案2
问题确实出invalidating query cache entries (table)在旧的非 Percona 服务器上，导致复制停止，直到缓存失效（这花费了大量时间）。
如下所述：http://bugs.mysql.com/bug.php?id=60696
我们通过完全迁移到 Percona MySQL 服务器 v5.5（该服务器具有完全禁用查询缓存的功能）解决了该问题。