MongoDB更改流中resumeAfter和startAtOperationTime之间的区别

Question

在版本4中，MongoDB更改流可以使用两个不同的参数来指定恢复更改流的位置：resumeAfter（某些内部令牌）和startAtOperationTime（时间戳类型）。

是否可以通过使用在每个变更事件中找到的resumeAfter，将startAtOperationTime完全替换为clusterTime，以安全地恢复变更流？

我特别担心并且无法在文档中找到确切信息的地方是：对于startAtOperationTime，是否有相同的规则和保证适用于可恢复的内容以及可恢复的时间。此处使用的操作时间是否正确保留，并且可以始终代替通常用于resumeAfter的文档令牌吗？

Answer 1

  

这里使用的操作时间是否正确保留，并且可以始终代替通常用于resumeAfter的文档令牌吗？

要使用哪种，取决于您的用例。

resumeAfter和startAtOperationTime这两个选项非常相似，只是存在细微差别：

• startAtOperationTime需要一个时间戳。 resumeAfter占用Change Stream事件文档的整个 _id。
• startAtOperationTime可以在invalidate event之后通过创建新的变更流来恢复通知。尽管resumeAfter在无效事件关闭流后无法恢复更改流。
• startAtOperationTime恢复在指定时间戳上或之后发生的更改。 resumeAfter在提供的令牌之后后立即恢复更改。

无论选择哪种标记，令牌或时间戳都应在Replica Set Oplog窗口时间内。变更流依赖于与分布式oplog同步的MongoDB全局逻辑时钟（集群时间），因此这两个选项都使用相同的基础技术。

值得一提的是，如果您想开始观看集合并处理该集合中的现有条目，则可以使用构造的时间戳记指定startAtOperationTime。使用resumeAfter很难做到这一点，因为它需要一个源自事件_id的令牌。

此外，MongoDB v4.2中的新增功能有一个新选项startAfter，该选项从事件中获取_id，并在恢复令牌中指定的操作之后恢复更改流。另外，它允许通知在无效事件之后恢复，就像startAtOperationTime一样。

您可能还会发现MongoDB版本上的compatibility table between resume tokens有用