[
https://issues.apache.org/jira/browse/COUCHDB-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761268#action_12761268
]
Matt Goodall commented on COUCHDB-516:
--------------------------------------
Also seen replicating between two Ubuntu machines (one Jaunty, one Karmic) both
running exactly the same version of CouchDB (git
9dfbf2ca3a9028262dff8e21637e41108701e9c3 from the 0.10.x branch, 820498 from
svn 0.10.x branch). Both machines on same network with no proxy, firewall, etc
in between. Replication was not continuous.
In my case the replication process did not end and I had to restart the CouchDB
server to continue.
> Replication: _replicate does not finish replication in one pass and has to be
> invoked repeatedly
> ------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-516
> URL: https://issues.apache.org/jira/browse/COUCHDB-516
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 0.10
> Environment: Mac OS X 10.5 w/ CouchDB 0.10.x multiple revisions
> (latest is 820436)
> Ubuntu Desktop 9.04 w/ CouchDB 0.10.x multiple revisions (latest is 818247)
> Reporter: Ning Tan
> Attachments: replication.txt
>
>
> When we replicate between a remote database and a local one (pulling from
> remote into local), we are observing partial replications, meaning that we
> have to issue repeated _replicate calls for the replication to complete. For
> a database with 17,000 documents, for example, it could take up to 7 calls
> for the entire database to replicate into an empty one. Each time, the number
> of documents replicated over seemed random.
> The use case is very simple--replicating a database into an empty one with no
> concurrent writes, no additional load or i/o, etc. The databases involved are
> a mixture of the 10.0.x code base natively built on Ubuntu and Mac.
> It seems to me that every (not all) partial replication process is associated
> with a corresponding entry in the log that says "recording a checkpoint at
> source update_seq .....". (i.e. you can match the recorded_seq number in the
> replication response with the checkpoint update_seq numbers in the log).
> Futon vs. curl doesn't make a difference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
