Elixir Cluster 101

One of the main super powers of Elixir (and other BEAM languages) is the built-in functionality for clustering nodes and communicating transparently across the cluster. Any distributed systems normally come with serious disclaimers. It’s very hard to get synchronized state across a cluster right, avoiding corrupted states during net splits or unreliable networks, dealing effectively with rolling deploys and mismatching versions of code.

But that shouldn’t discourage us. There’s a wide range of use cases for distributed Elixir, also known as disterl (and a bunch of other things, we really need a consistent name for this). You just need something that matches a few basic criteria:

It’s okay if some data is lost

It’s okay if some data is incorrect

As long as those criteria match, distributed Elixir, and distributed systems, are not actually that scary. Because it’s going to work most of the time, and for the use cases that match those criteria it’s frequently going to be a really good, low effort, and very performant option.

Where do you start

Before anything else, you need to ensure you’re starting your nodes in a cluster enabled configuration. If you’re using Phoenix and releases, this might just be a matter of editing env.sh.eex to add something like

export RELEASE_DISTRIBUTION = name

export RELEASE_NODE = app @$ ( hostname - i | awk '{print $1}' )

and to ensure DNSCluster is configured.

or if you’re trying this out locally, start a few nodes with

First terminal tab

iex -- name first @ 127.0. 0.1

Second terminal tab

iex -- name second @ 127.0. 0.1

They’re started in distributed mode, but are still not connected. Let’s do that next. Go to the tab for one of the nodes, let’s say first.

iex ( first @ 127.0. 0.1 ) 1 > Node. list

[ ]

iex ( first @ 127.0. 0.1 ) 2 > Node. ping (:"second@127.0.0.1" )

:pong

iex ( first @ 127.0. 0.1 ) 3 > Node. list

[:"second@127.0.0.1" ]

iex ( first @ 127.0. 0.1 ) 4 > Node. self

:"first@127.0.0.1"

And we’re conne…