CouchDBは、連続的な複製で、削除する代わりに文書のリビジョンを元に戻します。

Question

データベースとしてCouchDBを使用するシステムがあります。 継続的複製を使用して、常に更新されたデータベースのコピーを作成しています。

私たちは、通常のレプリケーション（フィルタリングませ）を使用してシステムを設定します。私はここで誰かが私を助けることができる願ってい

最近、我々は奇妙な行動（多分バグ？）を発見しました。

同じ文書を複数回連続して更新します（CouchDBが200okを返すのを待つたびに） - この部分は正常に動作し、文書は複製されたDBで正常に更新されたようです。

ただし、連続した更新後数分でもこの文書を削除しようとすると、複製データベースでは削除されず、連続して更新される前にリビジョンに戻されます。

私は削除して、いくつかの問題があることを理解真

にフィールドセットを_deleted我々がを追加することにより削除することに注意することが重要であるHTTP DELETEを用いてろ過し、レプリケーションと組み合わせて、しかし、我々は使用していませんどちらか。 また、同じアップデートを行い、もう一方を待つだけで問題は解決します（またはそれらを1つのアップデートに組み合わせるだけです）。 しかし、両方の解決策は不可能で、いずれの場合でも問題を回避するだけです。

TL; DR：通常の連続レプリケーション

2と

1）のCouchDB）連続更新は

3）_deleted =をtrue文書

4を文書化する）レプリケートDBが削除されません代わりに、＃2の前に_revに戻ります。

環境：

CouchDBのバージョンは、CouchDBの-のLuceneを使用して1.6.1

Windowsコンピュータ

であるあなたは、文書内の一部の競合を導入しているほとんどの

Answer 1

問題を解決しました。 改訂の制限でした。 リビジョンの制限を超える変更をすばやく行うと、レプリケーションメカニズムの問題が発生しているようです。

この問題についてのCouchDBで未解決のバグがあります：私たちが持っていたリビジョンの制限が同じ文書に3回の連続で更新を行うと、それがこの問題の原因となった削除、2だったので https://issues.apache.org/jira/browse/COUCHDB-1649

が。 リビジョン制限を5に設定すると、リビジョン制限が回避されます。

Answer 2

。ドキュメントが複数のレプリカで編集されている場合、CouchDBはレプリケート時に勝利したリビジョンを選択しますが、失われたリビジョンも保持します。勝利したリビジョンを削除すると、失われたリビジョンが再び表示されます。あなたはCouchDBの現在のガイドであるhttp://guide.couchdb.org/draft/conflicts.htmlとCouchDBのドキュメントを読むことができます：http://docs.couchdb.org/en/1.6.1/replication/conflicts.html

しかし要するに、レプリケーションデータベースは誰かによって編集されている可能性があります。複数のデータベースを1つに複製した場合や、ターゲットデータベースで手動で文書を編集した場合があります。

ターゲットデータベースを削除し、空のデータベースを再作成することができます。手作業でターゲットdbを編集せず、複数のdbsを1つに複製しない場合、_deletはそれ以降正しく複製されます。