【发布时间】:2014-02-09 23:56:11
【问题描述】:
我们有几个生产的 couchdb 数据库已经膨胀到 30GB,需要压缩。这些由 24/7 运营网站使用,并使用连续复制与另一台服务器复制。
根据我所做的测试,压缩这些数据库大约需要 3 分钟。
在生产站点和复制仍在运行时压缩复制的一侧是否安全?
【问题讨论】:
标签: couchdb database-replication
我们有几个生产的 couchdb 数据库已经膨胀到 30GB,需要压缩。这些由 24/7 运营网站使用,并使用连续复制与另一台服务器复制。
根据我所做的测试,压缩这些数据库大约需要 3 分钟。
在生产站点和复制仍在运行时压缩复制的一侧是否安全?
【问题讨论】:
标签: couchdb database-replication
是的,这是绝对安全的。
压缩的工作原理是在内存中构造新的压缩状态,然后将该新状态写入新的数据库文件并更新指针。这是因为 CouchDB 有一个非常严格的规则,即数据库文件的内部永远不会被更新,只会附加一个 fsync。这就是为什么您可以粗暴地杀死 CouchDB 的进程,而不必像在其他解决方案中那样恢复或重建数据库。
这意味着您需要额外的磁盘空间来重新写入文件。因此,尝试压缩 CouchDB 数据库以防止出现完整磁盘警告通常是行不通的。
此外,复制使用序列树(b+树)的内部表示。复制器不将整个数据库文件从磁盘传输到网络管道。
最后,当然会增加系统资源的利用率。但是,您的测试应该已经大致向您显示了与闲置 CouchDB 相比这在您的系统上的成本,您可以使用它来确定您将系统推到崩溃点的程度。
【讨论】:
我和CouchDB 合作已经有一段时间了;复制数据库并写入Views 以获取数据。
我已经看到了它的复制行为并观察到了这一点,可以回答您的问题:
触发此查询将显示所有数据库序列的更改。它只适用于最新版本的更改而不是以前的更改(所以我认为压缩不会造成任何伤害):
curl -X GET $HOST/db/_changes
结果很简单:
{"results":[
],
"last_seq":0}
更多信息可以在这里找到:CouchDB Replication Basics
这可能有助于您理解它。您的问题的简短回答是YES,在连续复制中压缩数据库是安全的。
【讨论】: