MySql服务器master-master的Seconds_Behind_Master跳转

Question

我正在运行一个 4 服务器的 MySql 主-主集群。（2 个服务器版本 5.1 和 2 个服务器版本 5.5）

在检查从站状态时，我看到 secondary_behind_master 为 0，半秒后我看到它跳到 2000，等等。

它可能是什么？我该如何调试它？

复制拓扑：1 -> 2 -> 3 -> 4 -> 1

更新

看来服务器 3 的 SBM 为 0，而其他服务器则上下跳跃。这有帮助吗？

UPDATE 2 看来问题出在服务器1上。在服务器4中创建测试表时，检查服务器1中的中继日志显示创建语句已立即复制到服务器1中的中继日志中，但未创建表。看起来服务器正忙于做某事，并且服务器获取语句和执行语句之间存在巨大的延迟。

更新 3 服务器 4 上也发生同样的情况。

更新 4 好吧，我发现了这个问题。服务器 1、2 和 4 的复制线程中卡住了“无效的查询缓存条目（表）”。禁用缓存后，服务器 4 正常，但 1 和 2 仍然存在此问题。

它看起来像一个常见的错误： http://bugs.mysql.com/bug.php? id=60696

如果有人知道如何解决它，我会很高兴听到

Answer 1

mysql 的 secondary_behind_master 值有一个缺陷：它只考虑相对于上游一跳的位置。最简单的演示是使用稍微简单的复制拓扑：

服务器1 -> 服务器2 -> 服务器3

如果 server2 落后，并且正在处理一些长时间运行的查询，假设 00:00 作为起始点，将会发生以下情况：

00:00：大家都好
00:01：server1 将两个 10 分钟的查询写入 binlog，任何地方都没有复制延迟
00:02：server2 开始处理查询 1。server2 的复制延迟开始增长，server3 的复制延迟保持为零
10:02：server2 已完成查询一，开始处理查询二。server2 复制延迟仍在增长。server3 复制延迟突然跳至10 分钟。
20:02：server2 完成查询 2，复制延迟再次为零。Server3 将完成查询 3，复制延迟跳回零，然后在处理下一个查询时跳回到 10。

因此，跳跃行为是由于没有使用全局时间戳来进行复制延迟而导致的，而只是复制链中最后一个“跃点”后面的延迟造成的。我们发现这非常烦人，现在使用 MySQL 的事件调度程序每秒更新每个主设备上的计时器表，因此我们实际上可以看到来自全局主设备（在非环拓扑中）的实际延迟或来自环中任何对等点的延迟。