couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Checking for cluster peers using SRV records on startup
Date Tue, 15 Nov 2016 01:25:06 GMT
> On Nov 14, 2016, at 4:10 PM, Dave Cottlehuber <> wrote:
>> On Fri, 7 Oct 2016, at 02:57, Adam Kocoloski wrote:
>> 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 Set”.
>> 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.
> belated +1 for _SRV records, +1000 for combining that with MDNS also for
> initial cluster setup. There are a number of erlang libraries already to
> help with this - below.
> the key issue with _SRV records is that, just like A records and CNAMEs
> is that you need to put them manually into DNS already. I am not sure
> this makes discovery easier...
> Something like mdns provides a multicast DNS lookup service, and nails
> this problem squarely.
> It is the bonjour/rendezvous/zeroconf tech used heavily by Apple
> devices, HP for printers etc. super nice. I am using this atm for
> service discovery albeit non-erlang stuff. It didnt quite get out of the
> RFC stage but its the defacto standard at least for consumer gear.
> or
> | client
> Also worth a look is with more
> docker sauce
> Another alternative is zbeacon, ,
> also with erlang implementation which
> I've only given a passing glance to.
> A+
> Dave

Hi Dave,

That makes sense. You can see I'm coming at this from the Kubernetes point of view, and in
that world Kube itself takes care of populating the SRV records to automate the service discovery.
I agree that if you have to populate the records manually you're not really gaining much.


View raw message