[DRBD-user] DRBD + OCFS2 - Split-Brain detected but unresolved

Felix Frank ff at mpexnet.de
Wed Apr 18 10:08:10 CEST 2012

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


On 04/17/2012 09:11 PM, Jacek Osiecki wrote:
>     after-sb-0pri discard-zero-changes;
>     after-sb-1pri discard-secondary;
>     after-sb-2pri disconnect;


> [287856.622136] block drbd0: Split-Brain
> detected, 1 primaries, automatically solved. Sync from this node

Acknowledged - your automatic resolution works fine.

>> A policy of discard-zero-changes could solve this for you, but only if
>> configured thus.
> Seems that my config is lacking this. 

It's not, your config is quite fine. (Although Linbit has suggested
"consesus" for the 1pri case in the past, which certainly appears safer
- if for any reason your one primary is the one that has old data, you
loose everything since then with discard-secondary).

Note that there is no safe sb-2pri setting to solve the split-brain
automatically. You really do not *want* DRBD to try and fix itself in
this situation.

In a dual-primary setup, a sufficiently bad network hiccup will cause
this split brain situation. That's why you want stonith to make sure you
don't end up with actually diverged datasets.

Long story short - if you have two primaries that disagree about
history, you want to handle this manually. As far as I know, the number
of bits that are set in the quicksync bitmap is a helpful clue that
tells you which node has had more changes written.

> Are there any mechanisms that would be capable of
> synchronizing the nodes (when node-node communication is up again) on
> filesystem level?

Tools like unison or rsync spring to mind. Still, even if you find a
sane way of doing a merge with those, there will be a lot of block-level
syncing to do *after* the merge.


More information about the drbd-user mailing list