MongoDB oplog包含许多noop

我正在尝试改进MongoDB服务器的oplog，因为目前它所覆盖的时间比我希望的要少（我现在不打算增加oplog文件大小）。我发现在oplog集合中有很多noops记录-{“op”：“n”}+整个文档都在“o”上。它们可能占物理oplog大小的20%-30%

我怎么能找到原因呢，因为它似乎不好

我们正在使用MongoDB3.6+NodeJS10+Mongoose

---

p、 它出现在许多不同的集合和用例中，因此很难理解所有这些项背后的应用程序逻辑。

MongoDB 3.4+副本集中不需要op写入，以支持帮助应用程序避免从过时的二级副本读取并提供更准确的复制延迟度量的。这些无操作写入仅在主设备空闲时发生。当前无法配置空闲写入间隔（如MongoDB 4.2）

Max Staleness规范包括一个示例场景和更详细的理由，说明了为什么会出现这种情况以及其他设计决策

设计原理的相关摘录：

空闲主设备必须每10秒执行一次no op（idleWritePeriodMS），以使辅助设备的lastWriteDate值接近主设备的时钟。no-op还使opTimes与primary保持接近，这有助于mongos在CSRS中选择最新的secondary进行读取

监控软件（如MongoDB Cloud Manager）记录复制延迟，在解决虚假延迟峰值时也将受益

---

Thx的答案，但我认为这是一个不同的情况。在我的例子中，它不是空的no-ops，而是一些更新操作的副本。他们实际上占了整个oplog的20-30%。在我的例子中，oplog是990MB，它覆盖了约20个小时。@MaksimKondratyuk为在假期中遗漏最后一条评论而道歉。我猜想这是使用findAndModify和可重试写入（类似于）的结果。使用retryable writes

find和modify

时，需要在oplog中写入成功更新的前一个状态，以便以幂等方式应用该更改。