1

couchdbレプリケーションでこの問題が発生しています：このセットアップドキュメントでreplicatordbを使用しています：

{
   "_id": "source_to_target",
   "_rev": "1-2a6510e28c2cc7caf0d58a85d705d2b8",
   "source": "http://xxxx:xxxx@localhost:5984/sourcedb",
   "target": "targetdb",
   "create_target": true,
   "continuous": true,
   "filter": "sourcedb/repl_filter",
   "query_params": {
       "someproperty": "somevalue"
   },
   "user_ctx": {
       "name": "someadmin",
       "roles": [
           "_admin"
       ]
   }
}

問題は、フィルター関数が無視されることです。私が呼び出すと、それは正しいと確信しています：

curl -X GET "http://localhost:5984/sourcedb/_changes?filter=sourcedb/repl_filter&someproperty=somevalue&feed=continuous&style=all_docs&since=0"

結果は正しくフィルタリングされます。

私は次のようにテストを実行します。

ターゲットデータベースを完全に消去します。次に、上記のレプリケーションを消去して、最初から再作成します。上記のレプリケーションドキュメントがコミットされるとすぐにレプリケーションが開始され、フィルタリングされたドキュメントの代わりに、ターゲットデータベースがすべてのドキュメントを取得します。これが私の問題です。ログは、その理由に関するヒントを提供します。

[Fri, 20 Jul 2012 17:43:38 GMT] [info] [<0.5860.17>] Replication records differ. Scanning histories to find a common ancestor.
[Fri, 20 Jul 2012 17:43:38 GMT] [info] [<0.5860.17>] no common ancestry -- performing full replication

レプリケーションを開始する前にターゲットデータベースを完全に消去するため、頭をかきむしります。まだ作成されていないデータベースを持つ一般的なアンカーを検索するのはなぜですか。どうやら私は何かが足りないようですが、それを理解することはできません。助言がありますか？

4

1 に答える 1

2

わかりました、ここに解決策があります：

smathy が示唆したように、別の新しいターゲット データベースを新しい名前で試すとうまくいきます。そのため、これによりログの検索が少し改善され、各テストで複製ドキュメントを消去していたにもかかわらず、それらの削除のどこかで、そのうちの 1 つが、引き続き稼働している基本的な複製プロセスを削除できなかったことがわかりました。だから、このゾンビのものは、新しいものはうまくいかなかったと私に思わせました。実際、それらは機能し、すべてのドキュメントを除外しましたが、ゾンビ レプリケーションは完全なレプリケーションを実行し続けました。

ゾンビが完全なレプリケーションを実行し、ログに多くを追加したため、実際には常に 2 つのレプリケーションが実行されていることをログで区別するのは困難でした。フィルター機能を無視するのは 1 つだけです。もっと注意深く見るべきだった。

とにかく、私は常に複製ドキュメントを消去/挿入することで futon で複製を開始し、コマンドラインやその他の方法から複製を開始したことはないため、複製ドキュメントを削除しても、基になる複製プロセスがキャンセルされるとは限りません。これについてもっと検索します。

于 2012-07-21T08:52:55.190 に答える