Hi,<br><br>Thanks for your answer , i only hava one last question.<br><br>I got two nodes one primary and one secondary like these:<br><pre style="font-family: arial;"><font><font size="2"><i>Node 1 connects to Node 2 by a switched network</i><i> and</i> <i>Node 1 connects to Node 2 by a crossover cable.<br></i><i>Consider the following software configuration:<br></i><i> <br></i><i>DRBD communicates over the switched network and</i> <i>Heartbeat (HA) communicates over both networks.<br></i><i>Now, following these steps I can repeat the case</i> <i>when  </i><i>i have both nodes in a standalone state which<br></i><i>require </i><i>user intervention to reconnect the current PRIMARY</i><i> DRBD node.</i></font></font></pre><pre style="font-family: arial;"><font><font size="2"><i>1.) Node 1 is DRBD Primary and Node 2 is DRBD</i> <i>Secondary<br></i><i>2.) I pull the switched network cable from node 1</i><i><br>3.) Node 1 detects the failure and HA moves the</i> <i>resources to
 node 2</i><i><br>4.) Node 2 is now StandAlone-&gt;Primary/Unknown and</i> <i>node</i> <i>1 is StandAlone-&gt;Secondary/Unknown<br>5.) </i></font></font><font><font size="2"><i>I </i><i>reconnect the switched network cable from node 1 </i></font></font>and it is at this moment when i got "split-brain".</pre>my question is, there is any posibility to avoid the "split brain" situation when y reconnect the cable from node1?<br><br>Thanks <br>Best Regards<br><br>Abraham OLIVARES<br><br><b><i>Lars Ellenberg &lt;lars.ellenberg@linbit.com&gt;</i></b> escribió:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> On Fri, Aug 10, 2007 at 12:57:03PM +0000, paddy@panici.net wrote:<br>&gt; On Fri, Aug 10, 2007 at 04:05:02AM -0500, Abraham olivares Varela wrote:<br>&gt; &gt; Hi everybody,<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; Does anybody knows how can i configurate the Automatic split-brain<br>&gt; &gt; recovery strategies,
 in order to avoid a "split brain situation". ?<br>&gt; &gt; <br>&gt; &gt; any example or any idea to do it that.<br>&gt; &gt; <br>&gt; &gt; please help me<br>&gt; &gt;<br>&gt; <br>&gt; On the one hand you talk about recovery and on the other hand you<br>&gt; talk about avoiding it.  <br>&gt; <br>&gt; I fear you may already be incurable ;-)<br>&gt; <br>&gt; <br>&gt; Do you *ever* want to go split brain.  are there scenarios for you where<br>&gt; that would be preferable and you want to think about what you are going <br>&gt; to do afterwards, or would you prefer to avoid it ever happening ?<br><br>basic problem is, that currently, with drbd 8 and two-primaries, as<br>necessary for cluster file systems, drbd will _always_ run into a<br>resource-internal (drbd specific) split brain as soon as you lose<br>the replication link, even if it is a very short network hiccup,<br>even if there has been no io on-the-fly.<br><br>that is because we did not yet implement any freeze-io due
 to loss of<br>write-quorum for drbd8 yet.<br><br>so as of now, if you want to use cluster file system with drbd8,<br>and you expect network hiccups, you run into "split-brain".<br><br>then you either always need to recover this by hand.<br><br>your you can configure some non-intrusive after-split-brain handler,<br>like the "discard-zero-changes", which would have nothing to "discard",<br>and "feature" auto-rejoin when there had been no-in-flight io, or no<br>changes on one side.<br><br>once you start using destructive settings,<br>"auto-recovery strategies" get very ugly very quickly, though.<br>and they are not a solution to the problem,<br>but only a work-around for those that commonly run into these problems,<br>e.g. people how configure two-primaries, but usually only accessing it<br>exclusively from one node (xen images). if you have a network hiccup<br>here, you will only have changes on one node, so you are fine with the<br>"discard-zero-changes"
 option.<br><br>solution is related to the implementation of (dynamically<br>reconfigurable) write-quorum, suspending IO as soon as we lose<br>quorum, then timeout, arbitrate, retransmit, resume ...<br>sorry, no time frame on that, besides "as soon as possible",<br>we are very busy with a lot of things around here :)<br><br>-- <br>: Lars Ellenberg                            Tel +43-1-8178292-0  :<br>: LINBIT Information Technologies GmbH      Fax +43-1-8178292-82 :<br>: Vivenotgasse 48, A-1120 Vienna/Europe    http://www.linbit.com :<br>__<br>please use the "List-Reply" function of your email client.<br>_______________________________________________<br>drbd-user mailing list<br>drbd-user@lists.linbit.com<br>http://lists.linbit.com/mailman/listinfo/drbd-user<br></blockquote><br><p>&#32;


      <hr size=1><br><font face="Verdana" size="-2">¡Sé un mejor ambientalista!<br><a href="http://us.rd.yahoo.com/mail/mx/tagline/beabetter/*http://mx.yahoo.com/promos/mejorambientalista.html">Encuentra consejos para cuidar el lugar donde vivimos</a>.<br></font>