【问题标题】:Is it safe to compact a CouchDB database that has continuous replication?压缩具有连续复制的 CouchDB 数据库是否安全?
【发布时间】:2014-02-09 23:56:11
【问题描述】:

我们有几个生产的 couchdb 数据库已经膨胀到 30GB,需要压缩。这些由 24/7 运营网站使用,并使用连续复制与另一台服务器复制。

根据我所做的测试,压缩这些数据库大约需要 3 分钟。

在生产站点和复制仍在运行时压缩复制的一侧是否安全?

【问题讨论】:

    标签: couchdb database-replication


    【解决方案1】:

    是的,这是绝对安全的。

    压缩的工作原理是在内存中构造新的压缩状态,然后将该新状态写入新的数据库文件并更新指针。这是因为 CouchDB 有一个非常严格的规则,即数据库文件的内部永远不会被更新,只会附加一个 fsync。这就是为什么您可以粗暴地杀死 CouchDB 的进程,而不必像在其他解决方案中那样恢复或重建数据库。

    这意味着您需要额外的磁盘空间来重新写入文件。因此,尝试压缩 CouchDB 数据库以防止出现完整磁盘警告通常是行不通的。

    此外,复制使用序列树(b+树)的内部表示。复制器将整个数据库文件从磁盘传输到网络管道。

    最后,当然会增加系统资源的利用率。但是,您的测试应该已经大致向您显示了与闲置 CouchDB 相比这在您的系统上的成本,您可以使用它来确定您将系统推到崩溃点的程度。

    【讨论】:

      【解决方案2】:

      我和CouchDB 合作已经有一段时间了;复制数据库并写入Views 以获取数据。

      我已经看到了它的复制行为并观察到了这一点,可以回答您的问题:

      1. 在复制过程中,文档的先前修订版不会复制到目标,仅复制当前修订版。
      2. 压缩数据库只会删除以前的修订。所以不会造成任何问题。
      3. 将在您当前登录的数据库上完成压缩。因此它不应该影响它的副本,它会不断地监听其中的变化。因为它侦听当前版本的更改而不是以前的版本。要验证它,您可以看到:

      触发此查询将显示所有数据库序列的更改。它只适用于最新版本的更改而不是以前的更改(所以我认为压缩不会造成任何伤害):

      curl -X GET $HOST/db/_changes
      

      结果很简单:

      {"results":[
      
      ],
      "last_seq":0}
      

      更多信息可以在这里找到:CouchDB Replication Basics

      这可能有助于您理解它。您的问题的简短回答是YES,在连续复制中压缩数据库是安全的。

      【讨论】:

      • 您的陈述“在复制过程中,文档的先前修订版不会复制到目标,只有当前修订版被复制”不太正确。复制目标尚未看到的修订树的所有边缘以及有关目标尚未看到的非边缘修订的元数据。获胜的修订版 - 您称之为当前修订版 - 是树中分支最长的版本(即,当您解决冲突时,您正在执行另一次写入以使该分支更长)。
      • 另外,您的第二点“压缩 [the] 数据库仅删除以前的修订版”需要更多细节。非边缘修订删除了它们的主体(文档),但标题仍然存在,因此尽管压缩,仍可以重新构建完整的序列树。对于已删除的文档也是如此;删除只是另一个带有一些特殊标志的文档。
      • 但在实践中,我看到复制的数据库不会启用任何“先前修订”按钮,因为它没有。并且复制数据库的大小将小于原始数据库,因为它不复制修订。这是我在实践中看到的。如果有人想要复制修订版,那么他将不得不稍微调整现有的复制器默认设置。
      • @SamBisbee 我给出了我的答案,以便提问的人应该理解它。我会包括抽象的细节,但那些不值得。这次我们需要明确的是关于复制(同步)中的问题,如果有的话?而且我还包括了序列检查查询,这将有助于获取数据库最新序列的变化。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多