couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: CouchDB Replication
Date Sun, 13 Feb 2011 05:42:32 GMT
On Sat, Feb 12, 2011 at 11:11, Jim Zombek <> wrote:
> What is the best way to determine what documents were replicated from source to
> target after a sucessfull replication?

(Let's try this as plain text)

Good question!

You can do something like this:

@target host
GET /target => {... "update_seq": X, ...}
POST /_replicate {"source": "<source host>/source", "target": "target"} => {...}
GET /target/_changes?since=X => { //here are your replicated changes }

This last request to /target/_changes will also include any writes to
the target database that occurred between the initial GET and
/_replicate as well as any writes that occurred after the replication
but before the /target/_changes request. If you can only make direct
requests against the target database then it is impossible to
guarantee an exact answer in the presence of concurrent updates to the

On the other hand, if you are performing a push replication from a
local database or can otherwise afford to request changes from the
source after the replication finishes, you can get exactly what you
want even in the presence of concurrent updates to the source and/or
the target using the response body from the replication request.

For push replication:

@source host
POST /_replicate {"source": "source", "target": "<target host>/target"} =>
  {..., "start_last_seq": A, "end_last_seq": B, ....}
GET /source/_changes?since=A&
limit=X => { //this is what you want }

where X = B - A.

For pull replication:

@target host
POST /_replicate {"source": "<source host>/source", "target": "target"} =>
  {..., "start_last_seq": A, "end_last_seq": B, ....}

@source host
GET /source/_changes?since=A&limit=X => { //this is what you want }

where X = B - A as above.

Both databases residing on the same host makes the push and pull cases
essentially identical (specifying source and target as both bare
database names [pull] or as both http endpoints [a sort of pull-push
with CouchDB acting as a middleman replication proxy])

Hope that helps.


View raw message