5

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

是否可以通过使用在每个更改事件中找到的安全恢复更改流来完全替换resumeAfter？startAtOperationTimeclusterTime

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

4

1 回答 1

6

此处使用的操作时间是否正确保留，是否可以始终用作 resumeAfter 通常使用的文档令牌的替代品？

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

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

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

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

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

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

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

于 2019-08-20T05:17:05.300 回答