<div dir="ltr">Thank you Jesper.<div><br></div><div>Best,</div><div>r.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 3:01 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 9:07 AM, Roberto Ostinelli <span dir="ltr"><<a href="mailto:roberto.ostinelli@widetag.com" target="_blank">roberto.ostinelli@widetag.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Adding to this: doesn't it mean that the name and full host of the node need to be known before you can initialize your db, hence a release can only be specific for a specific full node name?</blockquote></div><br></span>Indeed, distributed mnesia requires a node list when creating the schema. So this makes the database specific to the installation. This is not unique in any way, as RDBMS systems in general has this requirement of "pool initialization", where initial schemas, clustering and replication configuration has to happen. In this case, schema creation needs a separate target, and it is often beneficial to store the mnesia dir outside the release for easier upgrades.</div><div class="gmail_extra"><br></div><div class="gmail_extra">What I'm coming at is that mnesia was not created for idempotent database initialization. Other systems may be far better at this, where one can join new nodes to an existing system dynamically. The task is even automatic in some systems. But for mnesia, you need to write code. Code gives control and flexibility at the expense of simple deployment. On the other hand, you wont be surprised by system behaviour since you wrote the code yourself. Here is one way to go about it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Initialize a ``root'' which stores the schema and uses a predefined schema upon boot. Every other node now joins the cluster, with an empty schema. You start mnesia on a new node. You call `mnesia:change_config(extra_db_nodes, ['joiner@foo.bar'])` on root followed by `mnesia:change_table_copy(schema, 'joiner@foo.bar', disc_copies)` so the schema is on the disc of the newly joined node.</div><div class="gmail_extra"><br></div><div class="gmail_extra">From here, you can run `mnesia:add_table_copy(Table, 'joiner@foo.bar', Type)` to copy tables to the newly joined node for the tables which needs to be added.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In turn, you have two release configurations. One in which the node boots with a predefined schema, and one where it boots in a ram_copies schema mode and doesn't start operating before it has been joined to a cluster. Once it has been joined, it has a valid mnesia database and is ready for doing work in the cluster.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you want the ability to truly elastically add and remove nodes from a cluster, you probably shouldn't use mnesia. The reason has to do with mnesia's inability to automatically work with network splits and split brain. You can add nodes to mnesia ``up to a point'', after which you will have to move to another database system. As I've argued before[0], in the sense of the CAP theorem, mnesia is neither CP, nor AP and ``CA'' doesn't exist as a mode. Remember that mnesia predates the CAP theorem by a couple of years, and partitioning is highly unlikely in a system where communication is on the same cross-backplane as your telephony switching calls. For AP systems, Riak is perhaps the weapon of choice for Erlang programmers. For a CP system, I don't really have a good elastic candidate, but others may.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Where mnesia shines are:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* The cluster is of moderate size, perhaps less than 16 nodes.</div><div class="gmail_extra">* The FULL database can be in memory, or if using fragmented tables, loss of a fragment is not equal to total system catastrophe.</div><div class="gmail_extra">* Interaction between the Erlang processes and the data is tight, so having access to QLC is important.</div><div class="gmail_extra">* You have most queries as K/V lookups requiring microsecond latency with few complicated queries joining many tables. In the latter case, you care about correctness, not latency.</div><div class="gmail_extra">* The most likely failure is loss of a node. It happens rarely and it is possible to solve through manual intervention in a window of a couple of days/weeks.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[0] <a href="https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850" target="_blank">https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850</a></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div>J.</div>
</div></font></span></div>
</blockquote></div><br></div>