<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Lars Ellenberg wrote:
<blockquote cite="mid20050929130609.GA6116@barkeeper1.linbit"
type="cite">
<pre wrap="">/ 2005-09-30 00:58:34 +1200
\ Jonathan Wheeler:
</pre>
<blockquote type="cite">
<pre wrap="">#!/bin/bash
drbdadm=/sbin/drbdadm
if grep -q Unknown /proc/drbd
</pre>
</blockquote>
<pre wrap=""><!----> StandAlone would probably be more what you mean.
</pre>
</blockquote>
Thanks, will change :)<br>
<blockquote cite="mid20050929130609.GA6116@barkeeper1.linbit"
type="cite">
<blockquote type="cite">
<pre wrap="">For me... this has fixed my split brain problem. This still isn't
sophisticated enough to allow for a HA auto-fallback, but at least I
have data synced on both disks increasing my redundancy until a) I
switch back manually, or b) another failure takes out the failed over
node, in which case this will have saved my bacon.
Now, I might be misunderstanding exactly what drbd connect does. At face
value this appears to simply be initiating a connection with it's peer,
and it seems to me that this is something that drbd should be able to
take care of itself internally.
I have my connect-int set to 10 seconds, but from what I'm seeing here,
they try *ONCE* and give up. A simple retry (in the "other" direction)
should allow for a successful resync?
</pre>
</blockquote>
<pre wrap=""><!---->
they only give up if the situation won't change, i.e. if they know it
would be pointless, or worse, might risk your data.
if they recognize that you (might) have different versions of data on
the nodes, they try to avoid the automatic resync, because you might
chose an other direction than what might result from the automatic rules.
</pre>
</blockquote>
Understood, and thanks for the quick reply!<br>
I am still experimenting with drbd so I'm probably missing the
experience needed to understand why I would want to go the other way
around.<br>
<br>
I completely understand the desire to have this behaviour more
configurable rather then simply making the decision, and some people
might want this.<br>
<br>
<br>
However with the setup that I'm currently running, would you be so kind
as to point out any pitfalls with the configuration/scripts that I have
outlined?<br>
<br>
My simple train of thought is that drbd will only sync from primary
=> secondary when the primary node runs the connect command.<br>
The secondary (and probably bad) node can't initiate this, so there is
no danger of a bad node doing something bad, ie, overwriting the real
primary with my automated script in userspace. (obvious drbd already
protects against this in kernelspace)<br>
<br>
Thanks,<br>
Jonathan<br>
</body>
</html>