我正在尝试改进我的 MongoDB 服务器的 oplog，因为目前它覆盖的时间比我想要的要少（我暂时不打算增加 oplog 文件的大小）。我发现oplog集合中有很多noops记录-{“op”：“n”}+“o”上的整个文档。它们可能会占用物理 oplog 大小的约 20%-30%。
我怎么能找到原因，因为它似乎不太好？
我们正在使用 MongoDB 3.6 + NodeJS 10 + Mongoose
附言它出现在许多不同的集合和用例中，因此很难理解所有这些项目背后的应用程序逻辑是什么。
【问题讨论】：
标签： mongodb performance
为了支持Max Staleness specification，MongoDB 3.4+ 副本集中需要无操作写入，这有助于应用程序避免从陈旧的辅助节点读取数据并提供更准确的复制延迟度量。这些无操作写入仅在主节点空闲时发生。空闲写入间隔当前不可配置（如 MongoDB 4.2）。
Max Staleness 规范包含一个示例场景和更详细的理由说明为什么要使用 Primary must write periodic no-ops 以及其他设计决策。
设计原理的相关摘录：
空闲的主节点必须每 10 秒执行一次无操作 (idleWritePeriodMS)，以使辅助节点的 lastWriteDate 值接近主节点的时钟。 no-op 还使 opTimes 接近主节点的，这有助于 mongos 选择最新的从节点以在 CSRS 中读取。
监控软件（如 MongoDB Cloud Manager）在解决虚假的延迟峰值时也会受益。
【讨论】：
findAndModify 需要在 oplog 中写入成功更新的先前状态，以便幂等地应用该更改。