[DRBD-user] Avoid split brain in a dual primary configuration with intelligent switches

Lars Ellenberg lars.ellenberg at linbit.com
Wed Mar 18 19:53:54 CET 2009

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

On Tue, Mar 17, 2009 at 01:35:38PM +0100, Mario Giammarco wrote:
> I am replying to myself. Re-reading drbd documentation I finally found the
> write quorum explanation.
> And I discovered that why, using dual primary, I always get a split brain
> after a disconnection.
> Now I do not understand two things:
> - why single primary mode (master slave) does not need a write quorum;
> - how dual primary works. I think about this (mode C):

single primary: one node has "application writes in flight".
the other does not, it only has in flight what the Primary
was able to replicate to it so far.

replication link loss means that, at this point,
the "secondary", replication target, side,
is simply identical to the primary backend storage,
plus/minus some few write requests,
(plus, if the io subsystem on the primary was slow compared to the
replication link), which in drbd protocol B or C have not yet been
completed to upper layers -- so the upper layers are expected to be able
to cope with loss of them (if it was minus).

dual primary: both nodes potentially have "application writes in flight".

replication link loss means, that at this point,
in the general case, we have already diverging data sets.
not one side is stricktly ahead/behind the other.
but both sides differ in some non-trivial way.

: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
please don't Cc me, but send to list   --   I'm subscribed

More information about the drbd-user mailing list