[Linux-ha-dev] Re: [DRBD-user] drbd peer outdater: higher level implementation?

Lars Marowsky-Bree lmb at suse.de
Sat Sep 13 03:54:52 CEST 2008

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


On 2008-09-13T03:01:11, Lars Marowsky-Bree <lmb at suse.de> wrote:

Ahh, it all just clicked into place!

A slave always considers itself "outdated", until this flag is cleared.
(The flag is persistent in the meta-data.) While outdated, it refuses to
promote.

The "outdated" flag is cleared either by receiving a "stop" notification
for the peer (which pacemaker delivers), or that the peer has been
demoted (which we can either deliver using pacemaker, but of course drbd
knows via its internal protocol).

A primary, on loss of connection to the peer, freezes IO (sets the
outdated flag?). It invokes a call-out "crm_resource -F" _for the peer_,
which causes pacemaker to stop the peer. (Stopping the peer w/o
connection means that the peer will save its outdated flag to disk, and
be unable to promote.) The primary will then receive a "stop"
notification for the peer (either because it was indeed stopped, or
fenced), and then unfreezes (clears the outdated flag again?).

I think that covers everything for primary/secondary.


I'm not perfectly sure how to handle primary/primary; I believe the
second paragraph above handles it, but it would cause both sides to
stop; drbd might need some internal mechanism to pre-determine which
side will do that on primary/primary; it doesn't really matter which, I
think - maybe the lowest id?


Regards,
    Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde




More information about the drbd-user mailing list