Mongo Oplog 可尾光标

Question

我们正在使用 mongo java 驱动程序 3.2.2 和 mongo oplog 集合来识别我们的 mongo 集合中的变化（Mongo 服务器版本是 3.2）。我们遇到了以下 2 个问题，并且对此问题很少。如果你们中的任何人遇到过同样的问题，请帮助我们澄清它们。以下问题尤其是在 oplog 中有大量写入操作时会发生。

代码：

MongoCursor<Document> tailableCursor = collection.find(query).sort(new Document("$natural", 1)).cursorType(CursorType.TailableAwait).noCursorTimeout(true).iterator();

1. com.mongodb.MongoExecutionTimeoutException：操作超出时间限制

   a.) 设置 maxTime 是否有助于更好地处理异常？考虑到我们正在使用可尾等待光标，maxTime 的实际价值是多少？下面的链接表明，对于游标，后续的“getmore”请求将包含在总时间中。 https://www.mongodb.com/blog/post/maxtimems-and-query-optimizer-introspection-in

   b.) 使用非阻塞游标调用会有帮助吗？ http://mongodb.github.io/mongo-java-driver/3.4/javadoc/com/mongodb/client/MongoCursor.html#tryNext--

   c.) 如果出现上述异常，如何优雅地处理错误并继续处理后续记录？

2. com.mongodb.MongoQueryException: 查询失败，错误代码 96 和错误消息“查找命令期间的执行程序错误：CappedPositionLost:CollectionScan 因删除上限集合中的位置而死亡

   增加 Oplog 大小是否有助于解决此问题？是否有其他可用的替代解决方案？

Answer 1

长期以来，我们都面临着类似的问题。经过一番研究，我们发现这个官方文档很有帮助。

https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/

我们的问题是“复制滞后”

复制延迟是主节点上的操作与该操作从 oplog 应用到辅助节点之间的延迟。复制滞后可能是一个重大问题，并可能严重影响 MongoDB 副本集部署。过多的复制滞后使“滞后”成员没有资格快速成为主要成员，并增加了分布式读取操作不一致的可能性。

复制滞后的可能原因包括：

• 网络延迟
• 磁盘吞吐量
• 并发

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

• 适当的写关注

如果您正在执行需要对主节点进行大量写入的大数据摄取或批量加载操作，尤其是在未确认的写入问题的情况下，辅助节点将无法以足够快的速度读取 oplog 以跟上变化。 为防止这种情况发生，请在每 100、1,000 或其他间隔后请求写入确认写入关注，以便为辅助节点提供赶上主节点的机会。

我们按照“复制滞后的可能原因包括”部分做了两件事：

• 使用适当的写入问题重写插入代码
• 限制插入率

那么我们的问题就解决了。