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

Question

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

是否可以使用每个更改事件中的 clusterTime 将 resumeAfter 完全替换为 startAtOperationTime 以安全恢复更改流？

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

Answer 1

Is the operation time used here persisted correctly and can it always be used as a replacement for the document token usually used for resumeAfter?

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

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

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

无论选择哪个，token 或timestamp 都应该在Replica Set Oplog window 时间内。更改流依赖于 MongoDB 与分布式 oplog 同步的全局逻辑时钟（集群时间），因此这两个选项都使用相同的底层技术。

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

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

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