Distributed app using rebar3, backed up with Mnesia

I have a release using rebar3 which is composed of several apps (server, fsm, mnesia…).
I would like to make the system fault tolerant by creating another node with mnesia to make sure the data is backed up and ready to redeploy the server/fsm.
The problem is that since rebar3 is basically an escript, I can’t use erlang’s {kernal, [{distributed, [Nodes]}]... config to open the backup nodes automatically.
What is the best course of action to connect the app on a different node and synchronize the mnesia data? Do I have to create a whole handshake protocol on init / run of the app? It doesn’t make sense to me that I’m losing erlang’s ditributed capabilities because of rebar3…
I’ve looked at answers like this and this for a start, is this correct?

2 Likes

I had similar problem while trying to configure kernel on rebar3 startup. Try this solution.

1 Like

I would generally advise against using rebar3 as startup driver, and recommend learning releases.
See @MononcQc book: Releases | Adopting Erlang

4 Likes

We used to have a big warning when calling rebar3 shell that warned people not to use it in prod and to please use releases instead. We got rid of the warning since people didn’t like being told about it in dev every day for years, but yeah, the warning even if no longer there still stands.

You should use releases. Rebar3 has a few boot options and VM-level options set in the escript that are tailored to its workload and not a general one. Past development stages you should move to releases. There are even dev-mode releases that are assembled faster, which could be of interest to you.

5 Likes