couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: Checking for cluster peers using SRV records on startup
Date Thu, 27 Oct 2016 19:50:06 GMT
Hi Joe,

Ignore /_setup entirely, you're already well past that entry level. couchdb 2.0 and bigcouch
should be about the same in your terms. The main difference is the 'nodes' db was renamed
to '_nodes' to be more consistent with couch naming conventions, but you can change this back,
as Cloudant does, with the .ini file config system.
> On 27 Oct 2016, at 01:40, Joe Black <> wrote:
> This would be great, as I’m running into massive issues trying to get couchdb to cluster
in an automated fashion, with bigcouch this was no problem because you could simply use an
init container on kubernetes to craft the http call to the /nodes endpoint to add the current
nodes hostname, although adapting the http call to couchdb ie 5986/_nodes works from the init
container the same, it only works for the initial cluster, after creating the initial cluster
trying to add a new node by adding a new node to the nodes db fails to contact the node at
any time in the future, but does create the record.  This makes adding a node to a cluster
in an automated fashion seemingly impossible. :(
> I have tried also using the official _setup endpoints but those fail completely because
the add_node call is made before the new couch node is started, when failing to contact the
node the entire operation seems to be ignored rather than trying again in the near future.
 I’m considering just going back to bigcouch since it’s broken ops automation entirely
for us :(
> -- 
> Joe Black
> From: Adam Kocoloski <>
> Reply: <>>
> Date: October 6, 2016 at 9:57:55 PM
> To: <>>
> Subject:  Checking for cluster peers using SRV records on startup  
> Hi all,  
> Lately I’ve been thinking about how to ease the onramp for users to get a clustered
CouchDB setup running. I think the Kubernetes work shows a lot of promise. One of the aspects
of that work is the service discovery element; each node in a cluster should be able to automatically
find its peers and connect to them. Kubernetes accomplishes this using SRV records; a DNS
lookup for a given named service will return the FQDNs of all the live members of the “Pet
> The SRV approach is enough of a standard[1] that I wonder if we ought to code for it
directly in mem3. It’d eliminate the need for a “sidecar” container in Kubernetes deployments
and I can imagine that it will prove more generally useful. The idea would be for mem3 to
check if the CouchDB node is running in distributed node, and if it is, fire off a DNS lookup
on the domain name, then attempt to connect with any other targets that are included in the
record set in the DNS response.  
> What do you think? If no one objects I’ll file a JIRA and see what we come up with.
> Adam  
> [1]:

View raw message