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. Martin 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
