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