couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Multi node topology
Date Fri, 19 Aug 2011 18:29:23 GMT
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 <rob@lidalia.org.uk> 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
>>> 
> 


Mime
View raw message