couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Checking for cluster peers using SRV records on startup
Date Mon, 14 Nov 2016 22:10:12 GMT
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.


View raw message