couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ladislav Thon <>
Subject Replicating with two CouchDBs that share the same URL
Date Wed, 27 Jun 2012 16:38:23 GMT

we're using CouchDB (version 1.1.1 currently, but planning to upgrade to
1.2.0) because of its multi-master replication. The replication topology is
a simple star -- single central server and a number of clients that
replicate both from and to the central server. Writes are (almost) always
done on the clients.

Now for high availability, the central server isn't actually a single
machine, but two machines (and therefore two couches) whose IP addresses
are mapped to the same domain name (DNS round robin). These two couches
also replicate with each other. The clients don't know about this, they
always replicate from and to https://central.couch:6984/database.

This might not be the best architecture for HA and we would be able to
change it, but I'd still love to get an answer to this question: is CouchDB
able to cope with this? How does it know that it replicates with the same
couch it replicated with before (so that it only has to replay changes) and
how does it recognize that it replicates with a different couch than before
(and has to copy the whole database)?

I know that it was already proposed several times to add an UUID to CouchDB
server/database, which would solve this issue, and I also know that it's
very easy to end up with duplicates, which renders universallly
unique identifiers ... not so *unique* (i.e. useless).


Also, I have a question about replication monitoring. Are there some best
practices for monitoring whether the replication is working? I can of
course read the corresponding document in the _replicator database and look
at the _replication_state field, but this will only tell me that the
replication is *running* -- and I want to know that it's actually
*working*. For
now, we are using a pretty naive approach: 1. Every 10 minutes, write a
document with current date and time to the central couch. 2. Periodically
check on all clients (we have them under control) that the document isn't
too old. Is there a better approach?

Thanks for your opinions!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message