incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ladislav Thon <>
Subject Re: Replicating with two CouchDBs that share the same URL
Date Sat, 11 Aug 2012 13:38:30 GMT
Friendly ping? :-)


2012/6/27 Ladislav Thon <>

> Hi,
> 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!
> LT

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