couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Best Choice for redundant production environment?
Date Thu, 25 Jul 2013 23:33:10 GMT
Hi Dan, oops, sounds like the docs missed a port range there.  Each of your nodes is listening
for connections from the other nodes on a particular port.  That port is advertised by EPMD
on 4369.  You can control the range of ports that might be used in the vm.args file -- the
following directive placed in that file will force your nodes to listen on port 9100:

> # Limit the allowable port range for distributed Erlang
> -kernel inet_dist_listen_min 9100
> -kernel inet_dist_listen_max 9100

Regards, Adam

On Jul 25, 2013, at 4:21 PM, Dan Santner <> wrote:

> Thanks guys.  After a bit of wrangling I have bigcouch running!  Exciting stuff.  However,
does anyone know what ports I'm supposed to open for each node?  
> The doc only mentions 5984,5986, and 4369 but clearly that wasn't enough.  Started with
those three and every PUT gave me a 500 even though it saved to the specific node, just wouldn't
propogate to the others..
> So then I opened all the ports and it worked like a charm.  So clearly there are more
ports required than the three in the doc.  Is Erlang speaking over some others?
> Sorry if this is the wrong forum.
> Dan.
> On Jul 17, 2013, at 2:22 PM, Robert Newson <> wrote:
>> BigCouch provides redundancy and partitioning. By default, three
>> copies of the data, and uses a quorum mechanism which is generally
>> superior to three independent couchdb nodes inter-replicating.
>> And, of course, the BigCouch project is merging with CouchDB.
>> B.
>> On 17 July 2013 19:59, Nick North <> wrote:
>>> I run a production environment with three nodes several thousand miles
>>> apart with full-mesh replication - it behaves beautifully, seamlessly
>>> recovering from network outages, and I don't touch it for months on end. My
>>> particular setup is multi-master, so every node is a production one, and
>>> clients swap to another node if their local one goes down. Document ids are
>>> designed to be globally unique so that they can never clash between nodes,
>>> and it happens that the app never needs to edit documents, so there is no
>>> chance of multiple edits colliding.
>>> Nick
>>> On 17 July 2013 19:41, Dan Santner <> wrote:
>>>> I'm about to put together my production environment using couchdb as the
>>>> backend.  I've been running my test environment on a single linux node
>>>> (couchdb ver 1.2) for about a year without even restarting it once!  That
>>>> activity has actually been more than I can imagine in our production
>>>> environment, however, I'm nervous about going into production running a
>>>> single node.
>>>> question to you guys is this?  Do I look into running big couch,
>>>> and does that even handle redundancy or just sharding?  Do I simply setup
>>>> two nodes and let them cross replicate?  Cross replication just seems ripe
>>>> for problems, but I've never tried it so I'm asking you all what you'd do.
>>>> My production traffic will not be high by any measure.  There will be
>>>> bursts of activity but as mentioned, nothing a single node hasn't been able
>>>> to handle so far.
>>>> Any experiences you guys have to share is appreciated.
>>>> Dan.

View raw message