couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Goodall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-516) Replication: _replicate does not finish replication in one pass and has to be invoked repeatedly
Date Thu, 01 Oct 2009 16:57:23 GMT

    [ 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.


Mime
View raw message