mongodb - Mongo Oplog Tailable 游标

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/

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

Replication lag is a delay between an operation on the primary and the application of that operation from the oplog to the secondary. Replication lag can be a significant issue and can seriously affect MongoDB replica set deployments. Excessive replication lag makes “lagged” members ineligible to quickly become primary and increases the possibility that distributed read operations will be inconsistent.

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

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

In some cases, long-running operations on the primary can block replication on secondaries. For best results, configure write concern to require confirmation of replication to secondaries. This prevents write operations from returning if replication cannot keep up with the write load.

• 适当的书写关注

If you are performing a large data ingestion or bulk load operation that requires a large number of writes to the primary, particularly with unacknowledged write concern, the secondaries will not be able to read the oplog fast enough to keep up with changes. To prevent this, request write acknowledgement write concern after every 100, 1,000, or another interval to provide an opportunity for secondaries to catch up with the primary.

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

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

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