在版本 4 中，MongoDB 更改流可以使用两个不同的参数来指定恢复更改流的位置：resumeAfter（一些内部令牌）和startAtOperationTime，时间戳类型。
是否可以完全替代resumeAfter with startAtOperationTime通过使用安全恢复变更流clusterTime在每个变更事件中发现？
我特别关心并且在文档中找不到确切信息的是是否startAtOperationTime对于可以恢复的内容和持续时间，也适用相同的规则和保证。此处使用的操作时间是否正确保存，是否始终可以用作通常用于的文档令牌的替代品resumeAfter?
这里使用的操作时间是否正确保存，并且它始终可以用作通常用于resumeAfter的文档令牌的替代品吗？
使用两者中的哪一个取决于您的用例。
两个选项，恢复后 https://docs.mongodb.com/manual/changeStreams/#resumeafter-for-change-streams and startAtOperationTime，非常相似，但有细微的差别：
-
startAtOperationTime需要一个时间戳。尽管resumeAfter采取entire _id of a 改变流 https://docs.mongodb.com/manual/changeStreams/事件文档。
-
startAtOperationTime可以在一段时间后恢复通知使事件无效 https://docs.mongodb.com/manual/reference/change-events/#change-event-invalidate通过创建新的变更流。尽管resumeAfter无效事件关闭流后无法恢复更改流。
-
startAtOperationTime恢复发生的更改在或之后指定的时间戳。尽管resumeAfter立即恢复更改after提供的令牌。
无论您选择哪一个，令牌或时间戳都应该在副本集 Oplog https://docs.mongodb.com/manual/core/replica-set-oplog/窗口时间。更改流依赖于 MongoDB 全局逻辑时钟（集群时间），该时钟与分布式数据库同步oplog，因此这两个选项都使用相同的底层技术。
值得注意的是，如果您想开始观看集合并处理集合中的现有条目，您可以指定startAtOperationTime带有构造的时间戳。这样做会更难resumeAfter，因为它需要一个源自_id一个事件的。
另外，MongoDB v4.2 中新增了一个新选项startAfter这需要一个_id来自事件，并在恢复令牌中指定的操作之后恢复更改流。此外，它允许通知在无效事件后恢复，就像startAtOperationTime.
您还可能会发现恢复令牌之间的兼容性表 https://docs.mongodb.com/manual/reference/method/db.collection.watch/#resumability对 MongoDB 版本有用
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
