couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stephen bartell <>
Subject Re: Simple load-balancing replication best practices
Date Thu, 04 Oct 2012 19:52:38 GMT

On Oct 4, 2012, at 9:48 AM, Dave Cottlehuber wrote:

> On 4 October 2012 17: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.
> 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

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