couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Hewitt <>
Subject Re: Simple load-balancing replication best practices
Date Thu, 04 Oct 2012 15:26:58 GMT
We arrange our replication with all servers replicating to all others, which is higher in network
terms, but more reliable in terms of sudden failure. 

In my experience, if you try and create a replication to itself, it won't cause any problems,
it'll simply move to "completed", but I haven't tried that recently.

I do know that replication jobs are idempotent - i.e. if you have a replication job running
and try and create another that's to/from the same database, it won't create another job,
and it'll return the _id of the existing job. 


On Thursday, 4 October 2012 at 16:04, Steve Koppelman wrote:

> Assuming a hubless (i.e. not master-slave) set of 4 couchdb 1.2.0
> servers behind a load balancer, is there a recommended best-practice
> for setting up the replication relationships? I'm most interested in:
> * Assuming the _replicator document is on one of the two nodes in a
> relationship, is there a preference for push vs. pull replication
> relationships? I seem to recall pull as being regarded as more
> reliable than push through 1.1.1.
> * The new docs highlight replication of the _replicator database as a
> way to establish many-to-many replication. This raises two questions.
> 1. Is there harm in this sort of cluster to have all members to pull
> from one another, i.e., all of
> A->B
> A->C
> B->A
> B->C
> C ->A
> 2. Is there harm in full replication of _replicator if it results in
> documents that point a node to itself? That is, if I have a document
> that specifies a source of "localhost" and a destination as "node B",
> if this is replicated to node B this particular instance of the
> _replicator doc would set up an instance to replicate to itself, which
> doesn't sound good. Is it important to do filtered replication of
> _replicator when taking this approach?
> Rgds, etc.
> -sk 

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