我们使用mongo java驱动程序3.2.2和mongo oplog集合来识别我们的mongo集合中的变化（Mongo服务器版本是3.2）。我们遇到了以下两个问题，并且对此问题几乎没有任何疑问。如果你们中的任何人遇到过相同的问题，请帮助我们澄清它们。以下问题尤其发生在oplog中有大量写入操作时。
代码：
MongoCursor<Document> tailableCursor = collection.find(query).sort(new Document("$natural", 1)).cursorType(CursorType.TailableAwait).noCursorTimeout(true).iterator();
com.mongodb.MongoExecutionTimeoutException：操作超出时间限制
a。）设置maxTime有助于更好地处理异常吗？考虑到我们使用tailable await游标，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。）如果出现上述异常，优雅处理错误并继续处理后续记录的最佳方法是什么？
com.mongodb.MongoQueryException：查询失败，错误代码为96，错误消息'查找命令期间执行错误：CappedPositionLost：CollectionScan因封顶集合中的位置被删除而死亡
增加Oplog大小有助于解决此问题吗？还有其他替代解决方案吗？
答案 0 :(得分：2)
我们长期面对类似的问题。经过一番研究，我们发现这个官方文档非常有用。
https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/
我们的问题是“复制滞后”
复制延迟是主操作上的操作与该操作从oplog到辅助操作的应用程序之间的延迟。复制滞后可能是一个重要问题，可能严重影响MongoDB副本集部署。过多的复制滞后使“滞后”成员无法快速成为主要成员，并增加了分布式读取操作不一致的可能性。
复制延迟的可能原因包括：
在某些情况下，对主服务器的长时间运行操作可能会阻止对辅助服务器的复制。为获得最佳结果，请将写入问题配置为要求确认复制到辅助节点。如果复制无法跟上写入负载，这可以防止写入操作返回。
如果您正在执行需要大量写入主数据的大数据提取或批量加载操作，尤其是未确认的写入问题，则辅助数据库将无法足够快地读取oplog以跟上更改。 为了防止这种情况，请在每隔100,1,000或另一个间隔后请求写入确认写入问题，以便为辅助服务器提供赶上主服务器的机会。
我们遵循“复制滞后的可能原因包括”部分，并做了两件事：
然后我们的问题就解决了。