诊断和解决常见的 MongoDB 复制延迟问题

MongoDB 复制延迟不仅仅是仪表盘上的一个数字。它会改变应用程序的行为。用户更新了个人资料，另一个请求从从节点读取，返回的却是旧值。一个节点发生故障，但最佳的从节点仍然落后，因此故障转移所需的时间比预期的要长。一个报告查询落到了错误的成员上，突然间副本集看起来一切正常，除了一个从节点不断落后于主节点。

思考复制延迟的有用方法很简单：主节点生成 oplog 条目的速度快于一个或多个从节点获取和应用这些条目的速度。解决方法取决于您的环境中该句子的哪一半是正确的。有时主节点在突发情况下写入过多。有时从节点性能不足。有时网络速度慢。有时延迟是故意的，因为成员配置了 secondaryDelaySecs。您的首要任务是在做出更改之前区分这些情况。

从延迟的实际形态开始

不要一开始就调整 oplog 大小或重启 mongod。首先查明延迟是稳定的、突发的、仅限于一个成员，还是影响所有从节点。

在 mongosh 中，从以下命令开始：

rs.status()

查看每个成员的 stateStr、optimeDate、lastHeartbeatMessage 和健康字段。如果一个从节点落后而其他从节点正常，您可能遇到了特定成员的问题：磁盘、CPU、本地读取、本地维护或糟糕的网络路径。如果所有从节点都落后，请更仔细地检查主节点写入量、主节点网络吞吐量或异常大的操作。

要快速检查 oplog 窗口，请运行：

rs.printReplicationInfo()

oplog 窗口告诉您当前 oplog 覆盖的时间范围。这并不意味着复制是健康的。它表示一个从节点在需要初始同步之前可以落后多远。如果您的 oplog 窗口是 6 小时，而您的维护窗口通常需要 8 小时，那么即使当前延迟为零，您也面临着真正的操作风险。

对于从节点，以下命令也很有用：

rs.printSecondaryReplicationInfo()

在较旧的示例中，您可能会看到 rs.printSlaveReplicationInfo()。较新的措辞使用“secondary”，但较旧的 shell 帮助程序和较旧的博客文章可能仍使用“slave”。字段比名称更重要。

如果您想要一个用于实时 shell 的小脚本，请比较主节点 optime 和每个从节点：

const status = rs.status();
const primary = status.members.find(m => m.stateStr === "PRIMARY");

status.members
  .filter(m => m.stateStr === "SECONDARY")
  .forEach(m => {
    const lagSeconds = (primary.optimeDate - m.optimeDate) / 1000;
    print(`${m.name}: ${lagSeconds}s behind primary`);
  });

将其视为快照，而不是诊断。在批量导入期间落后 20 秒的从节点如果能够快速追赶，可能没问题。在正常流量下始终落后 20 秒的从节点则需要关注。

检查延迟是否是故意的

在追逐虚假事件之前，请检查副本集配置：

rs.conf()

延迟成员被设计为有意落后于主节点。在现代 MongoDB 配置中，查找成员上的 secondaryDelaySecs。该成员在某些恢复场景中很有用，因为它可以在短时间内保留数据的旧视图。它不应用于新鲜读取，并且其预期延迟应从正常的延迟警报中排除。

我在实际运维中看到的错误是对每个延迟成员都发出警报，好像它出了问题。对超出配置延迟的延迟发出警报。如果成员延迟了 1 小时，但显示 1 小时 5 分钟的延迟，则实际延迟约为 5 分钟。

当 oplog 窗口太小时

oplog 是 local 数据库中的一个固定集合。从节点读取它并按顺序应用操作。如果从节点落后太多，以至于主节点不再拥有它需要的 oplog 条目，则无法再进行普通的追赶。该成员通常需要初始同步或从合适的备份恢复。

这就是 oplog 窗口重要的原因。您希望它覆盖超过预期的停机时间、维护、网络中断和峰值写入突发。没有通用的“正确”oplog 大小。一个安静的集群可能在小 oplog 中保存数天的历史记录。一个具有大量更新的繁忙集群可能在短时间内消耗相同的大小。

如果在高峰流量期间 oplog 窗口正在缩小，请在下一个维护窗口之前增加它。在支持的 MongoDB 版本上，使用 replSetResizeOplog 而不是删除并重新创建 local.oplog.rs。删除副本集成员上的 oplog 是一种高风险恢复操作，而不是正常的调优步骤。

在要调整 oplog 的成员上运行调整大小命令：

use admin
db.adminCommand({ replSetResizeOplog: 1, size: 10240 })

size 值以兆字节为单位。10240 的值大约为 10 GB。根据需要调整每个成员的大小。在托管环境（如 MongoDB Atlas）中，使用平台支持的配置路径，而不是假设直接控制文件系统或进程。

调整大小后，在实际写入负载下验证新窗口。更大的 oplog 降低了从 oplog 中掉出的可能性，但不会使慢速从节点更快地应用操作。

当一个从节点速度慢时

如果只有一个从节点延迟，请登录到该主机并查看常见的系统症状。MongoDB 经常被指责为实际上是磁盘饱和的问题。

使用以下工具：

iostat -xz 1
vmstat 1
top
mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

高磁盘利用率、高等待时间或长 I/O 队列通常意味着从节点无法足够快地写入。当从节点使用更便宜的实例类型、EBS 或网络存储的预配置吞吐量较低，或者备份和文件系统快照与峰值应用程序写入同时运行时，可能会发生这种情况。

CPU 也可能很重要，尤其是在压缩、加密、文档移动、索引维护或具有许多小更新的工作负载下。内存压力表现为页面错误、缓存抖动以及从节点在尝试应用 oplog 条目时不断从磁盘读取。

实际的解决方法通常是乏味的：为从节点提供与主节点相当的存储和 CPU，减少该主机上的竞争工作，或将繁重的读取移到别处。副本集成员不是免费的报告容量。它仍然必须跟上复制。

当从节点上的读取导致问题时

使用从节点进行读取扩展很有用，但很容易过度。扫描大型集合的仪表板查询可能与 oplog 应用竞争。从节点可能仍然接受读取，但复制会落后，因为相同的 CPU、缓存和磁盘被用于用户查询。

检查延迟成员上的分析器和当前操作：

db.currentOp({ active: true })

如果您看到长时间运行的读取、聚合作业或维护脚本，请决定该从节点是否真的应该服务于该工作负载。对于报告，隐藏或专用从节点可能更合适。对于应用程序读取，设置 maxStalenessSeconds，以便驱动程序避免使用落后太多的从节点。

对于一致性关键的路径，请使用主节点读取。示例包括登录状态、结账确认、密码更改、帐户设置以及用户期望立即看到自己写入的任何内容。从节点读取最适合短暂延迟可接受的数据。

当主节点产生突发时

大量写入可能使健康的从节点看起来有问题。批量导入、大型多文档更新、TTL 清理、大型删除和索引更改可能会产生大量 oplog 活动，需要时间来应用。

检查主节点上的最近操作：

db.currentOp({ active: true })

还要检查应用程序部署、数据修复作业、回填和计划任务。恰好从 02:00 开始的复制延迟通常并不神秘。这是一个批处理作业。

当您控制作业时，将其拆分为更小的块。例如，按 _id 范围更新文档，在批次之间暂停，并在作业运行时观察延迟。使用 bulkWrite，无序写入可以提高吞吐量，但错误处理需要明确，因为失败可能是部分的。目标并不总是让主节点尽可能快地完成。目标是让副本集吸收工作而不失去其恢复余量。

索引和 Oplog 应用

在正常的副本集中，索引是复制的。如果由于手动工作、维护失败或节点恢复不正确而导致成员之间的索引不同，则从节点在应用更新和删除时可能会变得非常慢。oplog 操作可能需要查找文档，如果没有预期的索引，从节点可能比主节点做更多的工作。

比较受影响集合上的索引定义：

db.orders.getIndexes()

在主节点和延迟从节点上运行相同的命令。如果它们不同，请在做出更多更改之前找出原因。重建大型索引本身可能会产生负载，因此请在安静时段计划重建，或者如果差异很大，则从已知良好的源重建成员。

不要使用旧的建议，即后台索引构建可以解决所有复制问题。MongoDB 索引构建行为在不同版本中发生了变化，正确的操作选择取决于您的版本和拓扑。使用您运行的确切版本的当前服务器文档。

网络问题通常在其他地方可见

网络延迟通常表现为心跳不稳定、间歇性错误或特定主机或区域之间的吞吐量差。基本检查仍然有帮助：

ping primary.example.com
traceroute primary.example.com

但低 ping 延迟并不能证明足够的带宽。复制可能受到吞吐量、数据包丢失、防火墙检查、跨区域链路或嘈杂的共享网络的限制。如果延迟仅出现在远程从节点上，请将其与主节点同一区域的从节点进行比较。如果同一区域的成员正常而远程成员落后，则拓扑可能对链路要求过高。

对于跨区域副本集，要诚实地对待权衡。它们可以帮助灾难恢复，但更容易受到延迟和带宽限制的影响。如果远程成员用于读取，请使用延迟控制并测试故障转移行为，而不是假设它会像本地从节点一样运行。

谨慎对待重启和重新同步建议

重启 mongod 可以清除临时问题，但如果节点接近从 oplog 中掉出，也可能使事件变得更糟。在重启之前，检查 oplog 窗口和当前延迟。如果节点需要两小时才能追赶，而高峰流量期间 oplog 窗口只有三小时，那么长时间的重启可能会导致初始同步而不是追赶。

当从节点过时、损坏或缺少所需的 oplog 历史记录时，初始同步是一种有效的修复选项。但它也很昂贵。它会复制数据、构建索引，并从同步源消耗网络和磁盘资源。在生产环境中，最好一次添加或重建一个成员，以便副本集保留足够的投票和数据承载成员来容忍故障。

如果一个成员落后太多无法追赶，请采用符合您操作标准的新备份或基于快照的路径。不要因为清单上说就删除数据目录。确认该成员是可丢弃的，确认副本集可以容忍重建，并确认您有足够的 oplog 窗口或可靠的初始同步源。

对用户和运维人员关心的问题发出警报

好的警报不是针对每个系统的“复制延迟大于 1 秒”。某些应用程序可以容忍分析读取延迟 30 秒。其他应用程序无法容忍帐户状态的过时读取。警报阈值应反映用例。

有用的警报包括：

• 复制延迟超过应用程序容忍度持续一段时间。
• oplog 窗口低于最长预期维护或恢复间隔。
• 从节点处于 RECOVERING、STARTUP2 或不健康状态的时间超过预期。
• 任何数据承载成员的磁盘 I/O 饱和。
• 成员之间的心跳失败或网络错误。

仪表板应显示延迟以及写入量、磁盘延迟、CPU、内存压力和网络吞吐量。延迟本身告诉您存在问题。相邻的图表通常告诉您哪个问题。

实用的分类顺序

当您值班时，请使用此顺序：

1. 使用 rs.status() 确认哪些成员延迟。
2. 检查是否有任何延迟是由于 secondaryDelaySecs 故意造成的。
3. 使用 rs.printReplicationInfo() 检查 oplog 窗口。
4. 将延迟与写入峰值、批处理作业和最近的部署进行比较。
5. 检查延迟从节点的磁盘、CPU、内存和本地查询负载。
6. 检查受影响成员之间的网络错误和延迟。
7. 决定该成员是否可以追赶、是否需要移除负载、是否需要更多资源，或者必须重建。

最好的结果通常不是戏剧性的命令。而是找到瓶颈并消除它，而不造成数据分歧。当您将 MongoDB 复制延迟视为容量和拓扑信号，而不是通用的 MongoDB 故障时，它是可以管理的。