[DRBD-user] Clarification on How-To

Lars Ellenberg Lars.Ellenberg at linbit.com
Mon Sep 20 01:43:29 CEST 2004

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

/ 2004-09-17 18:10:21 +0100
\ Nuno Tavares:
> Alan,
> On Thu, 16 Sep 2004 20:30:45 -0600, Alan Robertson >Nuno Tavares
> wrote:
> >>
> >>This is *NOT* true, at least for 0.6.x, I still hadn't the time to 
> >>switch to 0.7.x though.
> >
> >Exactly *what* is not true?  
> Quote:
> "DRBD will never knowingly use out of date, and heartbeat will not
> override 
> that."

"knowingly" in the quote above obviously implies that both drbd
nodes are up and can talk to each other.

> I assume here that "out of date" is a comparative result between both
> DRBD. In that case, both nodes will keep to-be-mirror/secondary (not
> to-be-mirrored) even if it's the most up-to-date, if you set DRBD in
> passive mode (negative value in inittimeout).

drbd 0.6 and 0.7 are different.

in 0.6, synchronisation direction and beeing writable were tightly
coupled. therefore synchronisation should typically be done before
the cluster manager starts up.

if you use what you previously called "legacy" mode with drbd 0.6 and
heartbeat, then thats your fault, and without further hacking will cause
trouble and possible data loss an all sorts of things. but it possibly
increases your "availability". typically this was not used, but the sync
target instead was blocked in the boot process until the data was
completely synchronized before starting heartbeat. the sync-source node
did not block (relevant only after a complete cluster crash anyways).

> >DRBD will never use out-of-date data unless a human tells them
> >otherwise.  If it does, then that's a major bug, which would require
> >immediate attention.  That's pretty much all I said.
> I think you're missing my point here. DRBD *should* allow to be
> controlled externally (in terms of who's to-be-mirror[ed]). There are
> times that device writable control is preferred over to
> data-availability (my case). 

in drbd 0.7, a node can be SyncTarget and Primary at the same time.
(as long as the network link does not go down...)

> As I said, this might be different in 0.7.x, if DRBD is allowed to
> sync in both directions, still keeping a PRIMARY and (1-*)
> SECONDARY(IES). This should not be difficult, except for the fact when
> concurrent changes have to be dealed with. At this time, I think the
> PRIMARY should prevail... but this is subject to another thread, which
> I'm not able to start, without looking at the code (with time).
> >It doesn't matter which side is brought up as writable, and which as
> >non-writable. That's not terribly important, since it's easily
> >changed.  What's really important is which copy of the data is
> >treated as good.  In the older versions, this was tied tightly to
> >which side was "master".  In recent versions, that's not true any
> >more.
> So we have some kind of full-duplex going on here? :)


if you chose to make a SyncTarget Primary
(which is not recommended but possible),
it reads from the remote good copy where
it is not yet in sync.
writes are carried out as always.
resync happens "in the background".

> >Perhaps you missed that the discussion was about getting started the
> >first time.  This is a bit of a special case, since neither side has
> >known good data yet.
> I was not answering John, but rather correcting a potencial misleading
> information. I just wanted to state that DRBD internal detection of
> "who should be primary/writable" can be overridden.

nowadays (drbd 0.7) drbd does never decide who should be
primary/writable. it may refuse to become primary at first,
if it has inconsistent data, but you may always force it.

	Lars Ellenberg

please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list