libcluster VS libcluster_postgres

libcluster is the go-to package for connecting multiple BEAM instances and setting up healing strategies. libcluster provides out-of-the-box strategies and it allows users to define their own strategies by implementing a simple behavior that defines cluster formation and healing according to the supporting service you want to use.

I am using libcluster to connect my nodesI get the following error:

Distributed Elixir can be done with Docker containers too, see https://github.com/bitwalker/libcluster which by default has some Kubernetes support but you can also have third party (or custom) clustering strategies. I've not done this myself but I've seen articles about this a lot during the past years.

Hot code updates for most applications aren't really worth it in my opinion, assuming you do something like blue/green rollover deployments. It's cool that it's possible though. But it requires appup files and afaik Distillery is one of the release tools that has support for it built-in.

On the deployment level, you can use synchronous communication using API-based solutions or asynchronous communication using external solutions (RabbitMQ, Kafka,...) or Erlang/Elixir tools (message passing, pg2, PubSub, Libcluster,...)

Looking throught libcluster code (https://github.com/bitwalker/libcluster/blob/master/lib/strategy/kubernetes_dns.ex#L150) it does seem to require that both nodes share the same basename.

libcluster – Automatic cluster formation/healing for Elixir applications.

However, when it comes to connecting the servers, there seems to be a barrier of entry that many people encounter, including ourselves, on how to provide the name discovery required to connect said servers. We have released our approach to solving this problem by open-sourcing libcluster Postgres Strategy and today, we explore the motivations behind its creation and the methodologies employed in its development.

Ah, that makes a lot of sense - I think the FLAME.Parent{} approach may enable backends that wouldn't be possible otherwise.

For example, if I used the heroku api to do the equivalent of ps:scale to boot up more nodes - those new nodes (dynos in heroku parlance) could see what kind of pool members they are. I don't think there is a way to do dyno specific env vars - they apply at the app level.

If anyone tries to do a Heroku backend before I do, an alternative might be to use distinct process types in the Procfile for each named pool and ps:scale those to 0 or more.

Also, might need something like Supabase's libcluster_postgres[1] to fully pull it off.

[1] https://github.com/supabase/libcluster_postgres