我正在运行一个4服务器主 – 主集群的MySql。 （2个服务器版本5.1和2个版本5.5）
在检查从属状态的时候，我看到seconds_behind_master为0，半秒后我看到它跳到2000，所以第四。
它可能是什么？ 我怎样才能debugging它？
复制拓扑：1 – > 2 – > 3 – > 4 – > 1
UPDATE
看起来，服务器3的SBM为0，而其他服务器正在上下跳动。 这有帮助吗？
更新2似乎问题是与服务器1。在服务器4中创build一个testing表时，检查服务器1中的中继日志显示创build语句被立即复制到服务器1中的中继日志，但表不创build。 它看起来像服务器忙于做一些事情，服务器获取语句和执行语句之间有一个巨大的延迟。
更新3同样的事情发生在服务器4上。
更新4好吧，我发现了这个问题。 服务器1 2和4的“查询caching条目（表）”被阻塞在其复制线程中。 禁用caching后，服务器4是好的，但1和2仍然有这个问题。
它看起来像一个常见的错误： http : //bugs.mysql.com/bug.php?id=60696
如果有人知道如何解决，我会很高兴听到
mysql的seconds_behind_master值有一个缺陷：它只考虑相对于上游一跳的位置。 用一个稍微简单的复制拓扑来演示最简单：
server1 – > server2 – > server3
如果服务器2落后，并且正在处理一些长时间运行的查询，则会发生以下情况，假设00:00为起点：
00:00：大家好
00:01：server1向binlog写入两个10分钟的查询，在任何地方都没有复制延迟
00:02：server2开始处理查询一个。 server2的复制延迟开始增长，server3的复制延迟保持为零
10:02：server2完成查询一，开始处理查询二。 server2复制延迟仍在增长。 server3复制延迟突然跳到 10分钟。
20:02：server2完成查询2，复制延迟零再次。 Server3将完成查询3，复制延迟跳回到零，然后备份到10，因为它处理下一个查询。
所以，跳跃行为是由于没有使用全局时间戳来实现复制延迟而造成的，而仅仅是复制链中最后一个“跳跃”之后的延迟。 我们发现这非常恼人，现在使用MySQL的事件调度器来更新每个主节点上的一个计时器表，所以我们可以实际看到全局主节点（非环形拓扑结构）的实际延迟或环形结构中的任何对等节点的延迟。
问题的确是invalidating query cache entries (table)在旧的非Percona服务器导致复制暂停，直到caching失效（这花了很多时间）。
如此处所述： http : //bugs.mysql.com/bug.php?id=60696
我们通过完全转移到Percona MySQL服务器v5.5来解决问题，该服务器能够完全禁用查询caching。