<br><font size=2 face="sans-serif">Hi!</font>
<br><font size=2 face="sans-serif">You can force the node into primary
by issuing "drbdadm -- --overwrite-data-of-peer primary all".
This is quite selfexplanatory regardingits consequences when the other
node comes up again.</font>
<br><font size=2 face="sans-serif">if you issue a "drbdadm disconnect
all" after that you make sure it does not overwrite the other node
when it comes up, so you can do some recovery on the other node in case
you are missing some data and are lucky. "drbdadm connect all"
later on should reestablish the connection later on.<br>
</font><font size=3 color=#5f5f5f>Mit freundlichen Grüßen / Best Regards<br>
<br>
Robert Köppl<br>
<br>
Customer Support & Projects <br>
Teamleader IT Support<br>
<b><br>
KNAPP Systemintegration GmbH</b><br>
Waltenbachstraße 9<br>
8700 Leoben, Austria <br>
Phone: +43 3842 805-322<br>
Fax: +43 3842 82930-500<br>
robert.koeppl@knapp.com <br>
www.KNAPP.com <br>
<br>
Commercial register number: FN 138870x<br>
Commercial register court: Leoben</font><font size=3><br>
</font><font size=3 color=#d2d2d2><br>
The information in this e-mail (including any attachment) is confidential
and intended to be for the use of the addressee(s) only. If you have received
the e-mail by mistake, any disclosure, copy, distribution or use of the
contents of the e-mail is prohibited, and you must delete the e-mail from
your system. As e-mail can be changed electronically KNAPP assumes no responsibility
for any alteration to this e-mail or its attachments. KNAPP has taken every
reasonable precaution to ensure that any attachment to this e-mail has
been swept for virus. However, KNAPP does not accept any liability for
damage sustained as a result of such attachment being virus infected and
strongly recommend that you carry out your own virus check before opening
any attachment.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Xing, Steven"
<SXing@BroadViewNet.com></b> </font>
<br><font size=1 face="sans-serif">Gesendet von: drbd-user-bounces@lists.linbit.com</font>
<p><font size=1 face="sans-serif">31.01.2012 16:46</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">An</font></div>
<td><font size=1 face="sans-serif">"Kaloyan Kovachev" <kkovachev@varna.net>,
"Digimer" <linux@alteeve.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Kopie</font></div>
<td><font size=1 face="sans-serif">drbd-user@lists.linbit.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Thema</font></div>
<td><font size=1 face="sans-serif">Re: [DRBD-user] question about start
drbd on single node after a power outage</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Your response both faster, ;)<br>
Thanks all. I understand that there is a high risk of split brain and data
loss if force one node boot up.<br>
But in my case, service recover is much more important than data loss.<br>
<br>
I have 2 node pacemaker cluster, drbd running as master/slave(controlled
by pacemaker).<br>
When power outage on both nodes(just like unplug the power cable from both
node at the same time)<br>
Seems no chance for drbd to do anything(such as fence the peer), thus,
after I just boot up the previous primary node, <br>
I saw the pacemaker trying to promote the drbd to master, but failed, since
if I run drbdadm status, it shows:<br>
<br>
<drbd-status version="8.3.11" api="88"><br>
<resources config_file="/etc/drbd.conf"><br>
<resource minor="0" name="vksshared" cs="WFConnection"
ro1="Secondary" ro2="Unknown" ds1="Consistent"
ds2="DUnknown" /><br>
</resources><br>
</drbd-status><br>
<br>
I tried set both of the wfc time out to 5sec, that not work.<br>
<br>
As you can see the service drbd started, but can not be promote, since
ds1="Consistent", only "UpToDate" will work.<br>
Only when I boot up the other node, just after the 2 drbd instance connected,
drbd can declare disk status as "UpToDate".<br>
<br>
If not boot up the other node, I have not find an automatic way no matter
it is safe or not to force it think itself is "UpToDate".<br>
Seems the drbd did not remember its previous running status(primary or
slave) for some safe reason.<br>
<br>
Do you have any idea/comments on this? I looked into the doc, could not
find any setting can make this done even not safe. <br>
If I upgrade drbd to the latest version, will it help?<br>
<br>
<br>
-----Original Message-----<br>
From: Kaloyan Kovachev [mailto:kkovachev@varna.net] <br>
Sent: January-31-12 9:35 AM<br>
To: Digimer<br>
Cc: Xing, Steven; drbd-user@lists.linbit.com<br>
Subject: Re: [DRBD-user] question about start drbd on single node after
a power outage<br>
<br>
You were faster than me :)<br>
<br>
On Tue, 31 Jan 2012 09:04:49 -0500, Digimer <linux@alteeve.com> wrote:<br>
> <br>
> If you want to force the issue though, you can use 'wfc-timeout 300'<br>
> which will tell DRBD to wait up to 5 minutes for it's peer. After
that <br>
> time, consider itself primary. Please don't use this though until
<br>
> you've exhausted all other ways of starting safely.<br>
<br>
There are two (well documented) options in drbd.conf - wfc-timeout and
degr-wfc-timeout. To avoid split-brain i set both to 0.<br>
<br>
If you need to skip waiting you can manually do this from the console in
case you start drbd standalone or before cman / pacemaker.<br>
<br>
In my case it is exported via iSCSI (not as cluster resource), so have
additional wait loop for both nodes to became UpToDate for _all_ configured
resources before exporting any of them - 'no data' is better than 'broken
data' - yes i have been bitten from the last one (luckily during the preproduction
phase) and believe me you don't wan't that on production nodes (unless
you have static read-only data)<br>
_______________________________________________<br>
drbd-user mailing list<br>
drbd-user@lists.linbit.com<br>
http://lists.linbit.com/mailman/listinfo/drbd-user<br>
</font></tt>
<br>