[DRBD-user] Avoiding split brain

Matt Kocubinski mattkoco at gmail.com
Thu May 27 19:12:44 CEST 2010

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Ben:
Thanks for your suggestions:

> See: 5.3.2. Prevent Resources from Moving after Recovery
> At: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html

I had already followed the suggestions made here, as per the line in
my cib:

rsc_defaults $id="rsc-options" \
  resource-stickiness="100"

But, that does not seem to work in this case.  There is only one NIC
on each of the two boxes.  After reading, seems we should really
invest in 2 more NICs and a gigabit crossover cable, but that 
still won't solve all problems.

On Thu, May 27, 2010 at 04:19:47PM +0200, Lars Ellenberg wrote:
> 
> May I point to this thread:
> [Pacemaker] DRBD 2 node cluster and STONITH configuration
> does drbd really need stonith?
> 
> http://www.mail-archive.com/pacemaker@oss.clusterlabs.org/msg04312.html
> 
> where I try to explain the various scenarios,
> and what is needed to deal with them.
>

Good read, thank you.

Not sure why resource stickiness isn't work as expected, my
understanding was setting a high default stickiness would prevent
resources from moving about, which would solve the problem. However it
only works in this case:

node1 is master
node1 nic dies
node2 takes over
node1 comes back online
[A] resources stay on node2
split-brain, discard node1's data, all ok

but NOT this:
node2 is master
node2 nic dies
node1 takes over
node2 comes back online
[B] resources *move to node1* (why do they do this?)
outdated data on node1, clients connecting, potential for diverging
data sets. 

[A] is fine, [B] a problem.  granted, keeping node1 always as master is
reasonable, but not full-proof.

I would expect pacemaker's behavior to be symmetric, but it isn't, and
I need to find out way.




More information about the drbd-user mailing list