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