Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-05-14 00:09:20 +0100
\ Nuno Tavares:
> Em Thu, 13 May 2004 23:03:56 +0200, Lars Ellenberg escreveu:
>
> > / 2004-05-13 20:51:52 +0100
> > \ Nuno Tavares:
> >> Em Thu, 13 May 2004 08:17:25 +0200, Martin Bene escreveu:
> >>
> >> > Hi,
> >> >
> >> >> resource drbd0 {
> >> >> protocol = C
> >> >> fsckcmd = /bin/true
> >> >> inittimeout=-10
> >> >
> >> > Eep, what are you doing here? With this inittimeout you don't give drbd
> >> > sufficient time to connect with the 2nd node before trying to continue
> >> > startup on ist own.
> >> >
> >> > If you use inittimeout, it should be as a last resort kind of thing with
> >> > a timeout of -600 or something similar - this will still allow your
> >> > system to start if just one system comes up after a power fail.
> >>
> >> For testing purposes, -600 seems a lot to me!
> >> Anyway, what are the alternatives? "load-only"?
> >> As a matter of fact, I've considered and commented out inittimeout, and
> >> uncommented load-only, since my DRBD is heartbeat-managed.
> >> Is this the right way to do it?
> >
> > the point is: heartbeat does not know where the "most recent" data
> > lives. it only knows whether a node is up or not.
> > it will happily tell a node with outdated data to become primary.
> > thus you risk data corruption.
> > so only do this if you care more about availability than data interity,
> > i.e. it is more important to be online with *some* data,
> > than to be online with the most *up-to-date* transactions.
>
> That *is* my case.
>
> > this situation only happens after total failure anyways, so you should
> > give your nodes enough time to boot, and fsck, and whatnot, and give DRBD
> > time to connect and start to sync in the right direction.
>
> Thanks for the explanation. It will be documented.
> >From what I've understood, after a POWERFAIL, it's probably that a DRBD
> device (even if it was *NOT* primary) thinks that is has the most recent
> data. So inittimeout will give it a chance to boot, fsck (/ and other
> mounts), and sync itself.
NO!
A drbd does not "think" it has the best data.
It either *knows*, or it cannot yet know,
because it could not yet ask its peer whether that one did something
while this one was down.
If you read the example config file, you will find
"[ will do this or that depending on positive or negative value]
if connection could not be established within that time (seconds)."
In case you had a powerfail on *both* nodes at the same time, and they
both come up again at nearly the same time, the should be able to boot
within that period. If they are not, inittimeout is too short.
This should only timeout completely if the other node has more serious
problems and refuses to boot.
> The problem arives when DRBD switches its state. I think heartbeat is
> unable to know that...
>
> >> I'm just affraid that DRBD's algorithm contradicts what heartbeat thinks,
> >> so I didn't really care about DRBD choosing WHO should be Primary.
> >> Heartbeat will decide.
> >
> > but heartbeat does not know.
> > you have been warned.
>
> Yes, I'm aware of it. I meant that Heartbeat will decide, without care
> about who's the most recent. I need to:
> 1) minimize DRBD switching
> 2) be available the most time possible, uninterruptible.