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
