On Oct 4, 2012, at 9:48 AM, Dave Cottlehuber wrote: > On 4 October 2012 17:04, Steve Koppelman <[email protected]> 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. > > Hope somebody else comments on this, I'm interested to know if this > still makes a difference. > >> * 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 > > Multimaster Meshed Magic :-)
… only if _id's are unique. AFAIK, you need to address conflict resolution if _ids are similar. > >> 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? > > Should be fine. > >> Rgds, etc. >> >> -sk > > You might want to look at BigCouch which handles a lot of this sort of > stuff for you, as well as sharded views. But the feature set isn't > quite parity yet. > > A+ > Dave Stephen Bartell "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Einstein
