incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark J. Reed" <markjr...@gmail.com>
Subject Re: Multi node topology
Date Mon, 22 Aug 2011 11:20:09 GMT
Load balancing is not sufficient for all uses, in particular if you use the
changes APi. Different nodes have different sequence numbers, so if you
subscribe to the changes feed, lose the connection, and get a different node
on reconnect, you will lose track of your place, and either miss changes or
reprocess some.

On Monday, August 22, 2011, Robert Elliot <rob@lidalia.org.uk> wrote:
> No probs - we've got load balancers already available that we're familiar
with scripting and administering, so if the cluster is not partitioned
treating it as a single node is as easy for us just using our load
balancers.
>
> Rob
>
> ----- Original Message -----
>> From: "Paul Davis" <paul.joseph.davis@gmail.com>
>> To: user@couchdb.apache.org
>> Sent: Friday, 19 August, 2011 7:37:04 PM
>> Subject: Re: Multi node topology
>> Robert,
>>
>> Sorry for the confusion. I jumped to the conclusion that you'd want to
>> be looking at the four nodes as a single logical node which is what
>> those projects provide even beyond the sharding and partitioning.
>>
>> On Aug 19, 2011, at 1: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
>> >>>
>> >
>

-- 
Mark J. Reed <markjreed@gmail.com>

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