我正在尝试改进我的MongoDB服务器的oplog，因为目前它覆盖的时间比我想要的要少(我现在不打算增加oplog文件大小(。我发现oplog集合中有很多noops记录 - {"op"： "n" } + 整个文档在"o"上。它们可能会占用大约 ~20%-30% 的物理 oplog 大小。
我怎么能找到原因，因为它似乎不行？
我们正在使用 MongoDB 3.6 + NodeJS 10 + 猫鼬
附言：它出现在许多不同的集合和用例中，因此很难理解所有这些项目背后的应用程序逻辑是什么。
MongoDB 3.4+ 副本集中预计会有无操作写入，以支持最大过时规范，该规范可帮助应用程序避免从过时的辅助数据库读取，并提供更准确的复制延迟度量。这些无操作写入仅在主数据库空闲时发生。空闲写入间隔当前不可配置(如MongoDB 4.2(。
最大过时性规范包括一个示例场景和更详细的理由，说明为什么主设备必须编写定期无操作以及其他设计决策。
设计原理的相关摘录：
空闲主节点必须每 10 秒执行一次无操作 (idleWritePeriodMS(，以使辅助节点的 lastWriteDate 值接近主节点的时钟。no-op 还使 opTimes 接近主节点，这有助于 mongos 选择要在 CSRS 中读取的最新辅助数据库。
像MongoDB Cloud Manager这样绘制复制滞后图表的监控软件也将在解决虚假滞后峰值时受益。