Hi Robert, no, I wouldn't say that.  The projects Paul mentioned can simplify 
some of the setup of a multi-master deployment even if you don't take advantage 
of the sharding, but they're by no means required for it.

To answer your questions, push and pull replications are approximately equal in 
their efficiency these days.  The approach you outlined should be fine for a 
cluster of 4 nodes.  Cheers,

Adam

On Aug 19, 2011, at 2:21 PM, Robert Elliot wrote:

> Thanks; we're aware of both solutions, but as we do not currently need to 
> partition/shard we are interested in exploring what CouchDB could do by 
> itself, since it supports bi-directional replication.
> 
> Is the answer "the CouchDB developers recommend not running CouchDB in a 
> multi-master replicated topology"?
> 
> On 19 Aug 2011, at 18:26, Paul Davis wrote:
> 
>> Robert,
>> 
>> There are two projects for running CouchDB in a cluster:
>> CouchDB-Lounge and BigCouch. CouchDB-Lounge is a combination of an
>> nginx module and Python proxy that handles managing multiple backend
>> CouchDB nodes. BigCouch is a pure Erlang implementation that works
>> more like Dynamo.
>> 
>> [1] http://tilgovi.github.com/couchdb-lounge/
>> [2] http://github.com/cloudant/bigcouch
>> 
>> On Fri, Aug 19, 2011 at 8:32 AM, Robert Elliot <[email protected]> wrote:
>>> Hi,
>>> 
>>> We are considering setting up a cluster with more than two nodes. There is 
>>> a lot of documentation regarding two nodes but we couldn't find an exact 
>>> answer for let's say a cluster of 4 nodes.
>>> 
>>> Would you recommend a multi-master setup where all nodes receive writes?  
>>> This would be simpler to setup and administer, and would also be the most 
>>> fault tolerant (any combination of nodes can be shutdown so long as one is 
>>> still active).
>>> 
>>> If so, should we use only push replication?  Or only pull replication?  Or 
>>> a combination of both?
>>> 
>>> Assuming we are using pull replication within 4 nodes: A, B, C and D. 
>>> Should we set up A to pull changes from B, C and D, B to pull changes from 
>>> A, C and D, C to pull changes from A, B and D and D to pull changes from A, 
>>> B and C? Is this the recommended approach?
>>> 
>>> Thanks for any guidance,
>>> 
>>> Rob
>>> 
> 

Reply via email to