【问题标题】:Mongo permanent oplog, permanent Change Stream resumabilityMongo 永久 oplog,永久 Change Stream 可恢复性
【发布时间】:2021-01-31 16:49:50
【问题描述】:

我们在事件源项目中使用 Mongo 作为事件存储。我们的数据库只有一个副本仅用于支持事务,我们不会使用多副本、分片或 Mongo 的任何其他高级功能。

为了将事件投影到报告表的想法中,我们需要能够从历史中的任何点永久恢复“更改流”。我们只需要插入的历史,不再需要

为此,我们将恢复令牌和每次插入的操作时间连同它的 id 一起存储在一个单独的集合中,当我们想从历史中的某个插入恢复时,我们查询并找到确切的恢复令牌和我们从那里恢复它

这会导致一系列问题: 1-通过更改流存储恢复令牌和每次插入的操作时间是脆弱的,也需要存储,但有效!!!

2-我们最近达到了 oplog 的大小,发现 oplog 可以恢复,所以为了能够从历史中的任何点恢复,我们必须在应用程序的整个生命周期中存储并保留整个 oplog,但是 oplog 的大小每 2 小时就会达到最大容量! 所以无法保存oplog!

我们应该怎么做? 似乎除了在 Mongo 上实现历史变化流之外别无他法。

【问题讨论】:

    标签: mongodb


    【解决方案1】:

    要恢复变更流,恢复点必须在 oplog 中。因此,您的 oplog 需要返回到您希望恢复的位置。

    https://docs.mongodb.com/manual/tutorial/change-oplog-size/ 没有说明 oplog 大小的限制。您应该可以将其设置为任意大的尺寸。

    【讨论】:

      【解决方案2】:

      是的,没错。我向 MongoDB 提出了同样的问题,他们回答说我们必须在 oplog 中有恢复令牌,因此我们应该增加 oplog 的大小。但他们也说这样做不是一个好主意并且它不是为了永久使用它而设计的,它会在保留所有 oplog 时出现性能问题。所以他们建议使用他们的 Kafka 连接器来将事件和更改流式传输到 Kafka 主题中,然后从那里传输到我的投影仪中。这就是解决方案

      https://docs.mongodb.com/kafka-connector/current/

      【讨论】:

        猜你喜欢
        • 2014-02-21
        • 2012-08-26
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-07-19
        • 2019-01-26
        • 1970-01-01
        • 2021-12-25
        相关资源
        最近更新 更多