Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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." 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 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). 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? :) >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. >References: These were some (very interesting) documents/sites I refered to while writing the HOWTO, so this is not new to me, except for the fact that I usually don't remember author's names, which explains my reference to to it :) The point here was explaining what I was talking about, in a practical sense. Thanks for adding the link to Linux-HA. BTW, there was a typo in [5]. It's linuxha.trick.ca, not linux-ha.trick.ca :) Best regards, -- Nuno Tavares http://nthq.cjb.net/