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

Andrew Beekhof beekhof at gmail.com
Mon Sep 15 12:12:02 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 Sep 15, 2008, at 11:04 AM, Lars Ellenberg wrote:

> On Mon, Sep 15, 2008 at 10:26:46AM +0200, Andrew Beekhof wrote:
>> On Mon, Sep 15, 2008 at 08:28, Lars Ellenberg <lars.ellenberg at linbit.com 
>> > wrote:
>>>
>>> if we set aside confused admins for the moment,
>>> and assume CRM is the only entity promoting/demoting drbd.
>>
>> A very important assumption.
>>
>> Without it, it doesn't matter how much redundancy you add, you'll
>> always have a split brain/personality.
>>
>> You can't put the cluster in charge, tell it to go in one direction,
>> and then start trying to go off in another.  That path leads to
>> madness for the cluster and the admin.
>
> Absolutely. No disagreement there at all.

Cool.  Just wanted to make sure we're all on the same page... it  
wouldn't have been the first time someone went down the "other" path :-)

>
>
> The "outdated" flag stored in drbd metadata does help to remind the
> confused admin [1] that he meant to type that command in the other
> terminal window.
>
> That is all I wanted to say there.
> I just meant to point out this "subtile" difference
> in _where_ we store the information that this node is out-of-date.

Makes sense.

>
>
> [1] who tries desperately to rescue what he can after a minor
>    catastrophe, at 3:17 am Saturday morning

ouch



More information about the drbd-user mailing list