<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Sep 19, 2008 at 12:34 AM, Scott Lystig Fritchie <span dir="ltr"><<a href="mailto:fritchie@snookles.com">fritchie@snookles.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
JasonGanetsky <<a href="mailto:jason.ganetsky@gmail.com">jason.ganetsky@gmail.com</a>> wrote:<br>
<br>
jg> I will handle this, basically, by<br>
jg> shutting down the application on both nodes, clearing mnesia (which<br>
jg> is acceptable in this case), restarting mnesia, and then restarting<br>
jg> my application.<br>
<br>
Out of curiousity ... what does "clearing mnesia" mean?  Starting from<br>
scratch, deleting all Mnesia data?  Or something else?</blockquote><div><br>Deleting all Mnesia data. They way I'm using Mnesia for my application, it works... (it's to be avoided, but it's acceptable in the infrequent case of partition).<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
jg> I will not use mnesia:set_master_nodes(), as it<br>
jg> apparently causes the inconsistent_database message to be<br>
jg> suppressed.<br>
<br>
While the network partition was in effect, transactions on both sides<br>
may have done globally-inconsistent things ... but one won't know that<br>
until the partition is healed.</blockquote><div> </div><div>My question was not about the consequences of network partitions, but about how Mnesia detects and notifies.<br><br>Mnesia listens to nodeup messages. Any time it receives one, it performs an "inconsistency" check, by querying the new node for whether it had itself marked the queryer as mnesia_down. If this is the case, a running_partitioned_network message is generated. Transactions do not factor in to the inconsistency check at all.<br>
<br>Whenever a new node joins the ring, all nodes receive a nodeup message, so potentially, all nodes generate the running_partitioned_network message. Having a non-empty master_nodes list causes a node to always respond with "you are not mnesia_down", when queried. However, it still generates running_partitioned_network messages locally (as expected, since the other nodes may respond with "yes, you've been mnesia_down").<br>
<br>I discovered this by reading the Mnesia code, and by studying its behavior.<br><br>I've decided to have empty master_nodes lists on all my nodes, because I want all nodes notified in the event of a network parition.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
jg> My question is: how do I get them to reconnect? Should I do this by<br>
jg> simpling calling net_adm:ping() on the other node regularly? Or is<br>
jg> there a better way?  Also, am I correct in assuming that restarting<br>
jg> mnesia will cause them to re-sync?<br>
<br>
You'll need some excuse for one to communicate with the other.  If<br>
you're using default value of "-kernel dist_auto_connect" (not "once" or<br>
"false", see net_kernel(3)), net_adm:ping() is good enough.<br>
<br>
Upon restarting, the local Mnesia instance will need to contact other<br>
transaction managers to calculate the fate of any unresolved<br>
transactions.  That need will trigger re-connecting if dist_auto_connect<br>
is true.<br>
<font color="#888888"></font></blockquote><div><br>Does do anything with transactions? As far as I can tell, it simply dumps its replica and goes with whatever the other node has.<br></div></div><br></div>