MongoDB 副本集仅在一个节点上存在复制滞后

Question

我们在 MongoDB 副本集中遇到了奇怪的行为，设置了 3 个节点（所有 Xeon 四核 CPU，其中一个节点有 16GB RAM，另外两个节点有 24GB）RAM 较少的一个节点是正常的辅助节点，优先级为 0，其他两个节点优先级为 1。最近我们每 3 到 4 小时经历了一次大约 60 秒的复制滞后，2-3 分钟后自行消失（Nagios 检查！）

这些机器上几乎没有流量，只有一些大小为 0.3GB 的数据库，其中一个大小为 5GB。我们有一个集合，里面有大约 65000 个条目，还有一个ID指数。

奇怪的是，16gb 的辅助设备没有滞后，但只有两台较大机器的辅助设备有滞后。我只是将其更改为主设备，以查看旧的主设备（现在是辅助设备）是否也有此行为。

有人知道我们可以做什么或检查什么吗？因为我们一点头绪都没有。

我检查了这些机器的负载和进程、网络连接和路由、磁盘状态——一切正常。

Answer 1

一些快速检查：

• 你运行的是 2.0 或更低版本吗？复制功能在 2.2 版中进行了重大改进
• 你们有封顶收藏品吗？缺少索引在上限集合中的 _id 上可能会导致这种滞后
• 您提到主机并不太忙 - 如果您的新操作存在间隙，则用于计算延迟的数学运算可能会在未发生任何操作时错误地报告延迟
• 你是如何计算延迟的？我肯定会尝试从 shell - last optime 中的条目中确认任何延迟rs.status()是一个很好的开始
• 仔细检查网络方面的情况，延迟峰值和/或间歇性数据包丢失都可能导致这种情况，并且这种情况是暂时的，很难检测到（例如，查看netstat --statistics延迟峰值之前和之后的情况 - 看看重新传输或错误是否在增加）
• 如果你运行的是 2.2，请查看是否切换滞后辅助主机正在同步，这[syncingTo][3]在以下字段中有些令人困惑地显示出来：rs.status(). 这是通过rs.syncFrom()命令。
• 如果还没有，请将其放入彩信并查看是否有任何东西在滞后峰值的同时或前后出现峰值，以便为您指明正确的方向。

如果经过所有这些，您仍然不知道是什么原因导致了这种情况，那么可能无法以合理的方式在 serverfault 上回答（需要查看日志、统计数据等）——我建议您下一步访问 mongodb-user Google 群组。