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

Question

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

是否可以通过使用每个更改事件中的发现来完全替换resumeAfter以startAtOperationTime安全恢复更改流clusterTime？

我特别关心的是，我在文档中找不到确切的信息，即startAtOperationTime相同的规则和保证是否适用于可以恢复的内容以及持续多长时间。这里使用的操作时间是否正确保存并且它始终可以用作通常使用的文档令牌的替代品resumeAfter？

Answer 1

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

使用两者中的哪一个取决于您的用例。

这两个选项，resumeAfter和startAtOperationTime，非常相似，但有细微的差别：

• startAtOperationTime需要一个时间戳。WhileresumeAfter获取整个 变更流_id事件文档。
• startAtOperationTime可以通过创建新的更改流在无效事件后恢复通知。虽然resumeAfter在无效事件关闭流后无法恢复更改流。
• startAtOperationTime恢复在指定时间戳或之后发生的更改。在提供令牌后立即resumeAfter恢复更改。

无论您选择哪一种，令牌或时间戳都应该在副本集 Oplog窗口时间内。更改流依赖于与分布式同步的 MongoDB 全局逻辑时钟（集群时间）oplog，因此这两个选项都使用相同的底层技术。

值得注意的是，如果您想开始监视集合并处理集合中的现有条目，您可以指定startAtOperationTime构造的时间戳。使用 来做到这一点会更困难，因为它需要源自事件的resumeAfter令牌。_id

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

您可能还会发现MongoDB 版本上的恢复令牌之间的兼容性表很有用