<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<pre class="moz-signature" cols="72">Regards,
George P. Milliken
AvailMedia.com
406-752-6592 x1010
415-652-2105 (cell)
</pre>
<br>
<br>
James Wilson wrote:
<blockquote cite="mid:46BB0B24.2080702@transolutions.net" type="cite">
<pre wrap="">Thanks for the reply. I haven't had this happen on its own. I was just
testing by pulling the network cable to see if everything would failover
and noticed it when the other server came back up. Also to manually
resync them I just issue the command drbdadm invalidate "r0" or whatever
your resource is. Is this the wrong way to do it?
Lars Ellenberg wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Aug 09, 2007 at 09:39:51AM +0200, Pierguido wrote:
</pre>
<blockquote type="cite">
<pre wrap="">James Wilson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hey All,
I am running DRBD 8.0.3 in primary/primary mode. I tested my cluster
this morning by pulling the plug on one of the DRBD servers everything
worked out fine but when the server comes back up it doesn't resync and
is in secondary state for some devices and unknown for others. How can I
have the devices sync up and then become primary/primary again? Thanks
for any advice.
</pre>
</blockquote>
<pre wrap="">I have the same problem...i tried some things but nothing worked out.
Is there a sequence of command to do in these cases?
Thanks
</pre>
</blockquote>
<pre wrap="">you could configure some "auto-recovery strategies", see after-sb-#pri
settings in drbd.conf.
to get them reconnected and resynchronized manually,
you'd have to typically
chose one side to do
umount
drbdadm -- --discard-my-data connect XY
and maybe on the other side do normal
drbdadm connect XY
we are going to make this less annoying than it is now by introducing a
write_quorum and IO-freeze on disconnect, then we can timeout for a
possible imminent reconnect (network hiccup only), and after that
timeout arbitrate (triggered by the cluster manager) which side may
continue, and which has to be fenced (or let it self-fence...).
but for the time being, yes, I know, two-primaries is still "inconvenient"
when you have a flaky network.
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
drbd-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a>
<a class="moz-txt-link-freetext" href="http://lists.linbit.com/mailman/listinfo/drbd-user">http://lists.linbit.com/mailman/listinfo/drbd-user</a>
.
</pre>
</blockquote>
</body>
</html>