<br clear="all"><div class="post-text">
<p>i still have a number of challenges as regards mnesia fragmentation and replication. Consider the following scenario (The question am asking is based on what follows below):</p>
<pre>You have a data driven enterprise application which should be highly available <br>within the enterprise. If the internal information source is down for any reason,<br> the enterprise applications must switch to fetch data from a <b>recovery center</b> <br>
which is offsite (remote).
You decide to have the database replicated onto Two Nodes within the enterprise <br>(refered to as <b>DB side A</b> and <b>DB side B</b>). These two are running on separate<br> Hardware but linked together with say, a <b>Fast Ethernet or Optical Fibre link</b>. <br>
Logically, you create some kind of tunnel or secure communications between these <br>two Mnesia DBs. The two (A and B) should have the same replica of data and are<br> in sync all the time.
Now, meanwhile, the recovery center must too, have the same copy of data and in <br>sync all the time just in case the local data access is cutoff due to an attack <br>or hardware failure. So the same Database schema must be replicated across the 3 <br>
sites (<b>Side A</b> , <b>Side B</b> and <b>recovery center</b>).
</pre>
<p>Now, within the enterprise, the application middle ware is capable of
switching data requests amongst the database sites. If A is down, then
without the application realizing it, the request is re-routed to
Database B and so on. The middle ware layer can be configured to do load
balancing (request multiplexing) or to do be flexible with fail over
techniques.<br><br>
<b>Further Analysis</b>:</p>
<pre>At Database/Schema creation time, all involved Nodes must be up and running <br>Mnesia. To achieve this, you create say: <b>'<a href="mailto:db_side_A@domain.com">db_side_A@domain.com</a>'</b>, <br><b>'<a href="mailto:db_side_B@domain.com">db_side_B@domain.com</a>'</b> and finally, <b>'<a href="mailto:db_recovery_center@domain.com">db_recovery_center@domain.com</a>'</b>
</pre>
<p>Now, at Table creation, you would want to have your mnesia tables fragmented. So you decide on the following parameters:
<br></p><pre><b><i>n_disc_only_copies</i> =:= number of nodes involved in the pool =:= 3 </b>
<b>Reason:</b> You are following the documentation that this parameter regulates how <br>many disc_only_copies replicas that each fragment should have.<br>So you want each table to have each of its fragments on each mnesia Node.<br>
<b><i>node_pool =:= all nodes involved =:= ['<a href="mailto:db_side_A@domain.com">db_side_A@domain.com</a>',<br> '<a href="mailto:db_side_B@domain.com">db_side_B@domain.com</a>',<br>
'<a href="mailto:db_recovery_center@domain.com">db_recovery_center@domain.com</a>'] </i></b>
</pre>
All your tables are then created based on the following arrangement <pre>Nodes = [
'<a href="mailto:db_side_A@domain.com">db_side_A@domain.com</a>',
'<a href="mailto:db_side_B@domain.com">db_side_B@domain.com</a>',
'<a href="mailto:db_recovery_center@domain.com">db_recovery_center@domain.com</a>'
],
No_of_fragments = 16,
{atomic,ok} = mnesia:create_table(<b>TABLE_NAME</b>,[
{frag_properties,[
{node_pool,Nodes},
{n_fragments,No_of_fragments},
{n_disc_only_copies,length(Nodes)}]
},
{index,[]},
{attributes,record_info(fields,<b>RECORD_NAME_HERE</b>)}]
),
</pre>
NOTE: In the syntax above, <code>RECORD_NAME_HERE</code> cannot be a variable in reality since records must be known at compile time with Erlang.
>From the installation, you see that for each table, every fragment, say, <code>table_name_frag2</code>, appears on every Node's file system.
<p><b>Challenges and arising Questions</b>:<br>
After following what is listed down above, your first database start is
okay since mnesia is running on all nodes. Several challenges start to
show up as the application runs and am listing the below:<br><br>
<b>1. </b> Supposing, you decide that all writes are first tried on <code>DB Side A</code> and if side A at that instant is unavailable, the call is re-tried on <code>DB Side B</code> and so on to <code>recovery center</code>,
and if the call fails to return on all the 3 database nodes, then the
application network middle ware layer reports back that the database
servers are all unavailable (this decision could have been influenced by
the fact that if you let applications randomly write to your mnesia
replicas, its very possible to have inconsistent database errors showing
up in case your mnesia nodes lose a network connection with each other
yet writes are being committed on each by different Erlang applications.
If you decide on having <code>master_nodes</code>, then you could be at risk of loosing data). So by behavior, you are forcing <code>DB Side A</code> to be the master. This makes the other Database Nodes Idle for all the time as long as <code>DB Side A</code>
is up and running and so as many requests as hit side A and it does not
go down, No request will hit side B and recovery center at all.
<br><br>
<b>2. </b> Mnesia on start, normally, should see all involved nodes
running (mnesia must be running on all involved nodes) so that it can do
its negotiations and consistency checks. It means that if mnesia goes
down on all nodes, mnesia must be started on all nodes before it can
fully initialize and load tables. Its even worse if the Erlang VM dies
along with Mnesia on a remote site. Well, several tweaks and scripts
here and there could help restart the entire VM plus the intended
applications if it goes down.<br>
To cut the long story short, let me go to the questions.</p>
<p><b>Questions</b>:<br>
<b>1. </b> What would a Database administrator do if mnesia generates events of <code>inconsistent_database, starting to run database behind a partitioned network</code>, in a situation where setting a <code>mnesia master node</code> is not desirable (for fear of data loss) ?
<br>
<b>2. </b> What is the consequence of the mnesia event <code>inconsistent_database, starting to run database behind a partitioned network</code>
as regards my application ? What if i do not react to this event and
let things continue the way they are ? am i loosing data ?
<br>
<b>3. </b> In large mnesia clusters, what can one do if Mnesia goes down
together with the Erlang VM on a remote site ? are there any known good
methods of automatically handling this situation ?
<br>
<b>4. </b> There times when one or two nodes are unreachable due to
network problems or failures, and mnesia on the surviving Node reports
that a given file does not exist especially in cases where you have <code>indexes</code>.
So at run time, what would be the behavior of my application if some
replicas go down. Would you advise me to have a master node within a
mnesia cluster ?
<br><br>
As you answer the questions above, you could also highlight on the
layout described at the beginning, whether or not it would ensure
availability. You can give your personal experiences on working with
mnesia fragmented and replicated Databases in production. In reference
to the linked (quoted) question at the very beginning of this text, do
provide alternative settings that could offer more reliability at
database creation, say in terms of the number of fragments, Operating
system dependencies, node pool size, table copy types e.t.c. Thanks guys</p>
</div><br>-- <br><font size="4"><b><span style="font-family:courier new,monospace">Muzaaya Joshua</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Systems Engineer</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace">+256774115170</span></b></font><br><br>