压缩具有连续复制的CouchDB数据库是否安全？

Question

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

从我完成的测试开始，大约需要3分钟来压缩这些数据库。

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

Answer 1

是的，这非常安全。

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

这意味着您需要额外的磁盘空间来重写该文件。因此，尝试压缩CouchDB数据库以防止出现完整的磁盘警告通常是非启动性的。

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

最后，当然会增加系统资源利用率。但是，您的测试应该大致向您显示您的系统与空闲CouchDB相比的成本，您可以使用它来确定您将系统推向断点的程度。

Answer 2

我一段时间以来一直与CouchDB合作;复制数据库并编写Views以获取数据。

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

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

启动此查询将显示所有数据库序列的更改。它只能根据最新的修改而不是之前的修改（所以我认为压实不会造成任何伤害）：

curl -X GET $HOST/db/_changes

结果很简单：

{"results":[

],
"last_seq":0}

可以在此处找到更多信息：CouchDB Replication Basics

这可能有助于您理解它。简而言之，您的问题是是，在连续复制中压缩数据库是安全的。