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

Lars Marowsky-Bree lmb at suse.de
Sat Sep 13 04:00:34 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:48:45, Lars Ellenberg <lars.ellenberg at linbit.com> wrote:

Insomniac too? ;-)

> > No. Normal fail-over will only occur after 'we' have demoted/stopped the
> > peer. The cluster manager is quite good at enforcing dependencies ;-)
> unfortunately it does not know about the "up2date" ness dependency.
> that is the point.

But it doesn't need to. An not-uptodate drbd will simply refuse to
promote, right?

> > On the secondary, until you get a signal that the peer is dead
> > (stopped/demoted), consider yourself "not eligible" to be promoted (ie,
> > outdated).
> once outdated, it is outdated.
> there is only one way for outdated, stale, data
> to become uptodate again: resync.

I think implicit in this is indeed that the meaning of "outdated"
changes. Maybe a better phrase would be "eligible to promote". And
indeed, it is only cleared by reconnecting to the other side and
resyncing. Please see my other mail.

> it does not cover "replication link is down".

Please see my other mail. I think I explained it more clearly there.

> I describe simple situations,
> you could comment inline when and which notifications would take place.

I'm sorry, I wasn't aware that that was what you were looking for, and
the web page describes all scenarios when pacemaker delivers a
notification to an RA (basically, whenever the peer changes state).

> Iff I'd get a signal in the RA with the appropriate meaning
> at the appropriate time, I'd just say "drbdadm outdate resource".
> that is what dopd does now.

I think that "outdate" mechanism as it stands today might need some
minor changes, yes. Just as the logic in the RA surely needs to, and
possibly we even need to improve m/s if we find a lack there.

(Though right now I think most is contained to drbd + the RA.)


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