【问题标题】：CouchDB with continuous replication reverts document revision instead of deleting具有连续复制的 CouchDB 恢复文档修订而不是删除
【发布时间】：2016-07-12 21:22:03
【问题描述】：

我们有一个使用 CouchDB 作为其数据库的系统。我们正在使用连续复制来创建我们数据库的始终更新的副本。

最近我们发现了一个奇怪的行为（可能是错误？），我希望这里有人可以帮助我：

我们将系统设置为正常复制（不过滤）。

我们连续多次更新同一个文档（每次都等待 CouchDB 返回 200ok） - 这部分工作正常，并且文档在复制的数据库中似乎更新得很好。

但是，当我们尝试删除此文档时，即使在连续更新几分钟后，它也不会在复制数据库中删除，而只是恢复为连续更新之前的修订。

需要注意的是，我们通过将 _deleted 字段设置为 true

来删除

我了解使用 HTTP DELETE 与过滤复制相结合的删除存在一些问题，但我们都没有使用。此外，进行相同的更新并在一个和另一个之间等待一秒钟就可以很好地解决问题（或者只是将它们组合到一个更新中）。然而，这两种解决方案都是不可能的，无论如何只能解决问题。

tl;博士：

1) 具有正常连续复制的 CouchDB

2) 对文档的连续更新

3) _deleted = trueto 文档

4) 复制的 DB 不会删除，而是恢复到 #2 之前的 _rev

环境：

CouchDB 版本是 1.6.1

Windows 电脑

使用 CouchDB-Lucene

【问题讨论】：

只是为了确定，每当您在文档上将 _deleted 设置为 true 时，该属性都不会复制到您的复制数据库？
说对了一半。并不是说复制数据库中的文档根本不受影响。它恢复到早期版本。当我用 ?all_rev=true 检查它时，我可以看到较新的修订确实获得了 _deleted=true 属性，但连续更新之前的修订没有。这就是为什么，我猜，它成为复制 CouchDB 在要求提供文档时返回的修订版。然而，主 CouchDB 将 _deleted=true 添加到其所有修订版中。
只是一个更正。当我写“?all_rev=true”时，我的意思是“open_revs=all”

标签： couchdb replication

【解决方案1】：

您很可能在文档中引入了一些冲突。当一个文档在多个副本中编辑时，CouchDB 在复制时选择一个成功的修订，但也会保留失败的修订。如果您删除获胜的修订，失败的修订将再次显示。您可以阅读（现在有些过时的）CouchDB 指南中的介绍：http://guide.couchdb.org/draft/conflicts.html 和 CouchDB 文档：http://docs.couchdb.org/en/1.6.1/replication/conflicts.html

但简而言之，复制数据库可能已被某人编辑。可能是您将多个数据库复制到一个数据库中，或者有人在目标数据库中手动编辑了文档。

您可以删除目标数据库并重新创建一个空数据库。如果您不手动编辑目标数据库并且不将多个数据库复制为一个，则_deletes将从那时开始正确复制。

【讨论】：

【解决方案2】：

问题解决了。这是修订限制。似乎快速进行超过修订限制的更改会导致复制机制出现问题。

CouchDB 中有一个关于这个问题的未解决的错误： https://issues.apache.org/jira/browse/COUCHDB-1649

由于我们的修订限制是 2，对同一个文档进行 3 次连续更新然后删除它会导致这个问题。将修订限制设置为 5 可以避免它。

【讨论】：