Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to avoid a split brain situation using automatic split brain recovery policies explained at

How to predict which condition we are involved in? How to predict the number of primaries after split brain? Is it all accidental?

share|improve this question
up vote 1 down vote accepted

How many nodes do you have? More than two?

Anyway I found the following setup to be the best to recover from split-brains:

  1. after-sb-0pri: discard-zero-changes
  2. after-sb-1pri: discard-secondary
  3. after-sb-2pri: disconnect

So first we throw away any differences in the bitmaps where no changes were written. Second - if there was some fencing active and some higher-level switched one side to primary - then throw away the secondary changes - this keeps the most recent changes, but propably your now secondary has not been in the primary role long. Third if that did not help you have to resolve this manually.

I might cite Douglas Admams here: "Don't get bitten" (from "Last Chance to See"). There are many possible ways on how to "get bitten" by a split brain. So it depends on your specific setup and why you got into the split-brain situation.

I try to avoid these by using at least three different hearbeat-lines for the clustering above. These three lines should not have any common point of failure. There is at least one very intelligent (commercial) cluster solution that stops reacting if the reaction could lead to a split brain situation. But for the small money solutions stick to the rule of at least three really independent lines...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.