<div>Hi Martin,</div>
<div> </div>
<div>I would say self explanatory of DRBD users' guide (<a href="http://www.drbd.org/users-guide-emb/re-drbdconf.html">http://www.drbd.org/users-guide-emb/re-drbdconf.html</a>) and example drbd.conf file states:</div>
<div><span class="term"><code class="option">startup</code> </span></div>
<dd>
<div><a class="indexterm" id="id2657492"></a>This section is used to fine tune DRBD's properties. Please refer to <span class="citerefentry"><span class="refentrytitle">drbdsetup</span>(8)</span> for a detailed description of this section's parameters. Optional parameters: <code class="option">wfc-timeout</code>, <code class="option">degr-wfc-timeout</code>, <code class="option">wait-after-sb</code> and <code class="option">become-primary-on</code>. <br>
</div></dd>
<dd>
<div><br>The thing that people usually realised too late is that default setting for wait-for-connection setting is 0 which means wait for peer connection forever or manual intervention. Such setting will block your boot up process in case DRBD service is started at boot up time.<br>
</div></dd>
<dd>
<div>Re 2A) No, if you set reasonable wait for connection timeout interval. The same is true for your cluster manager here. Only node that has UpToDate data set can become Primary - it depends on how much changes with which speed have to be synced into B until it will become consistent and be able to be promoted into Primary role.</div>
</dd>
<dd>
<div>Re 2B) The same as 2A, however DRBD will most likely detect split brain after devices get connected as there were changes on both nodes since disconnection.</div></dd>
<div> </div>
<div>You are right, DOPD only works if there is at least one cluster manager communication path left when DRBD communication is interrupted. So when one node goes down immediately, there is no way to set its data as outdated.</div>
<div> </div>
<div>With regards.</div>
<dd>
<div> </div></dd>
<div class="gmail_quote">2009/2/13 Martin Fick <span dir="ltr"><<a href="mailto:mogulguy@yahoo.com">mogulguy@yahoo.com</a>></span><br></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I have a question about DRBD that has been bugging me for a while, perhaps someone can help me? :)<br><br>
I am concerned about the "cluster boot" phase of drbd. What I mean is, I am concerned about how to deal with both nodes in a cluster going down (not necc. synchronously) and what happens after one or both of them comes back up.<br>
<br>It seems like most heartbeat/drbd combinations expect both nodes to come up or they will (should?) not proceed to allow a node to become primary, is this correct?<br><br>In other words, suppose:<br><br>1) node A is primary and node B goes down. Node A stays primary and continues to process writes. Eventually, node A then also goes down.<br>
<br><br>2A) node A comes backup while B is still down. Node A will wait until it communicates with node B and will not get promoted. When node B comes up, either node may become primary. Is this correct?<br><br><br>2B) node B comes backup while A is still down. Node B will wai until it communicates with node A and will not get promoted. When node A comes up, either node may become primary. Is this correct?<br>
<br><br>dopd seems like a neat feature to outdate a peer when communication is lost, but it will not come into play in these situations, will it?<br><br>Thanks,<br><br><br>-Martin<br><br><br><br><br><br>_______________________________________________<br>
drbd-user mailing list<br><a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br><a href="http://lists.linbit.com/mailman/listinfo/drbd-user" target="_blank">http://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
</blockquote><br>