复制延迟故障排除

网络延迟

当集群节点彼此无法可靠通信时，可能会构建复制延迟。

检查副本集节点之间的网络路由，确保不存在数据包丢失或网络路由问题。

使用包括 ping 在内的工具来测试设立节点之间的延迟，并使用 traceroute 来公开网络端点之间数据包的路由。

或者，运行replSetGetStatus 并检查 pingMs字段。这将返回主节点 (primary node in the replica set)和从节点(secondary node from replica set)节点之间的当前网络延迟（以毫秒为单位）。

从节点资源耗尽

当从节点(secondary node from replica set)无法有效处理来自主节点 (primary node in the replica set)的传入读取操作时，可能会出现资源争用。这可能会导致缓存争用等内存问题。当缓存达到关键阈值时，服务器会使用应用程序线程逐出页面，从而减少可用于管理复制的线程数。

要查看服务器是否将应用程序线程重定向到逐出任务，请在 mongosh Shell中运行以下命令：

db.serverStatus().wiredTiger.cache['pages evicted by application threads']

• 如果结果 = 0：没有应用程序程序线程因驱逐而暂停。

• 如果结果 > 0（且不断增加）：数据库面临缓存压力。传入查询必须在执行之前逐出缓存的数据，这可能会增加复制延迟。

Atlas用户还可以监控WiredTiger Cache Activity 和 Page Faults指标，以调查缓存相关问题。

有关解决此问题的潜在策略，请参阅扩展资源。

磁盘相关问题

如果节点从节点(secondary node from replica set)无法足够快地将脏数据刷新到磁盘，它就会落后于主节点 (primary node in the replica set)。当来自主节点 (primary node in the replica set)的写入量超过从节点(secondary node from replica set)磁盘的写入速度时，就会出现这种现象。

与磁盘相关的问题在多租户系统（包括虚拟化实例）中普遍存在，如果系统通过IP网络访问磁盘设备，这些问题可能是暂时性的。

要评估磁盘状态，请使用系统级工具，例如 iostat 或 vmstat。

Atlas用户可以访问Atlas指标如Disk IOPS 和 Disk Space Used 来调查磁盘问题。

磁盘问题的一些常见原因包括：

• 预配不足：从从节点(secondary node from replica set)的磁盘速度比主节点 (primary node in the replica set)慢，或 IOPS 低。

• 虚拟化开销：在共享环境中，其他虚拟机可能会使物理磁盘控制器饱和。

磁盘问题的一些可能的解决方案包括：

• 增加预配IOPS

• 升级到 NVMe 存储

• 升级到更高的Atlas 集群层。有关更多信息，请参阅Atlas集群大小调整和层级选择。

长时间运行的操作

在某些情况下，主节点上长时间运行的操作可能会阻止从节点上的复制。为获得最佳结果，请将写关注配置为需要确认复制到从节点。这样可以防止在复制跟不上写入负载时返回写入操作。

您还可以使用数据库分析器来识别与观察到的延迟相关的慢速查询或长时间运行的操作。

写入负载过多

批量写入操作可能会超出副本集的及时复制能力，从而导致复制延迟。

以下小节提供了此问题的可能解决方案：

db.collName.deleteMany({createdDate: {$gte: new Date("2018-12-01"), $lt: new Date("2019-01-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-11-01"), $lt: new Date("2018-12-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-10-01"), $lt: new Date("2018-11-01")}});

db.collection.createIndex({ status: 1 });

db.collection.deleteMany({ status: "inactive" });

oplog window Size

如果oplog window对于要同步的数据量来说太小，则可能会遇到复制延迟。较大的oplog可以为副本集提供更大的延迟容忍度。

要检查给定副本集成员的oplog大小及其操作的日期范围，请连接到 mongosh 中的该节点并运行rs.printReplicationInfo() 方法。oplog应足够长，以容纳您对从从节点(secondary node from replica set)预期的最长停机时间内的所有事务。[1] oplog至少应能够保存至少 24 小时的操作；但是，许多用户更愿意有 72 小时甚至一周的工作时间。

要更改 Oplog 大小，请参阅更改自管理副本集成员的 Oplog 大小教程。