我们有一个使用CouchDB作为其数据库的系统。 我们使用连续复制来创建数据库的始终更新副本。
最近我们发现了一个奇怪的行为(也许是bug?),我希望有人可以帮助我:
我们将系统设置为正常复制( NOT 过滤)。
我们连续多次更新同一文档(每次等待CouchDB返回200ok) - 这部分工作正常,文档似乎在复制的数据库中更新得很好。
但是,当我们尝试删除此文档时,即使在连续更新后几分钟,它也不会在复制数据库中删除,而只是在连续更新之前恢复为修订版。
请务必注意,我们通过将 _deleted 字段设置为 true
来删除我知道使用HTTP DELETE和过滤复制删除存在一些问题,但我们也没有使用。 此外,执行相同的更新,只需在一个和另一个之间等待一秒即可解决问题(或者只是将它们组合到一个更新中)。 然而,这两种解决方案都是不可能的,无论如何只是解决问题。
1)具有正常连续复制的CouchDB
2)对文档的连续更新
3)_deleted = trueto document
4)复制数据库不会删除,而是在#2
之前恢复为_revCouchDB版本为1.6.1
Windows电脑
使用CouchDB-Lucene
答案 0 :(得分:0)
您很可能在文档中引入了一些冲突。在多个副本中编辑文档时,CouchDB会在复制时选择获胜版本,但也会保留丢失的修订版本。如果删除获胜的修订版,将再次显示丢失的修订版。您可以在(现在有点过时的)CouchDB指南中阅读介绍:http://guide.couchdb.org/draft/conflicts.html和CouchDB文档:http://docs.couchdb.org/en/1.6.1/replication/conflicts.html
但简而言之,复制数据库可能已由某人编辑过。可能是您将多个数据库复制到一个数据库中,或者有人在目标数据库中手动编辑了文档。
您可以删除目标数据库并重新创建一个空数据库。如果您不手动编辑目标数据库并且不将多个数据库复制到一个数据库中,则从那时起将正确复制_deletes。
答案 1 :(得分:0)
问题解决了。 这是修订限制。 似乎快速进行超过修订限制的更改会导致复制机制出现问题。
CouchDB中有一个关于此问题的未解决的错误: https://issues.apache.org/jira/browse/COUCHDB-1649
由于我们的修订限制为2,对同一文档进行3次连续更新然后删除它会导致此问题。 将修订限制设置为5可以避免它。