Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
IMHO, the web site should make it a little clearer that protocol B is not safe for active/active even when there is no failure, as from the description it could (wrongly) be assumed that in memory buffers are in sync on both nodes: Protocol B. Memory synchronous (semi-synchronous) replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred, and the replication packet has reached the peer node. Normally, no writes are lost in case of forced fail-over. However, in the event of simultaneous power failure on both nodes and concurrent, irreversible destruction of the primary's data store, the most recent writes completed on the primary may be lost. > -----Original Message----- > From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user- > bounces at lists.linbit.com] On Behalf Of Lars Ellenberg > Sent: Tuesday, December 13, 2011 4:14 PM > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] protocol B in dual-primary mode > > On Tue, Dec 13, 2011 at 09:11:25AM -0700, Marcus Sorensen wrote: > > On Tue, Dec 13, 2011 at 8:52 AM, Marcus Sorensen <shadowsor at gmail.com> > wrote: > > > On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg > > > <lars.ellenberg at linbit.com> wrote: > > >> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote: > > >>> "in dual primary mode, only protocol C is allowed. > > >>> > > >>> cluster file system deals with cache coherence, > > >>> DRBD has to deal with storage coherence. > > >>> you cannot do that asynchronously. > > >>> > > >>> to do that in protocol B, the receiving node would need to be able to > > >>> access data of in-flight requests, which is not implemented." > > ^^^ > You even quoted the paragraph. > Anything unclear about that? > > > > >>> > > >>> But what if you're not using a filesystem? > > >> > > >> Ok, so you are using "whatever", and you think you want dual-primary > DRBD, > > >> but you want it to replicate asynchronously despite of that. > > >> > > >> What if "whatever" writes something to node A, > > >> node A completes the write, > > >> and "whatever" has all right to assume this actually hit stable > storage. > > >> > > >> Then (the same or a different instance of) "whatever" wants to read > that > > >> change from node B, but the change is not yet on B, because it > > >> replicated async. > > >> > > >> "whatever" would be slightly surprised, > > >> and you would start screaming drbd ate my data. > > >> > > >> Well, no, it did not. You screwed up. > > >> And this particular screwup DRBD does not allow. > > > > > > So you're saying that protocol B, in active-active, would not read > > > from memory on the second node. So even if we wait until a write to > > > block 213456 has replicated to memory on node B, if a read comes in > > > for block 213456 on node B, it's going to go to disk for the read, and > > > ignore the outstanding write until it's on disk. This is good to know, > > > and not what I would have expected. > > > > Ah, for clarification, in protocol B we're not talking about the write > > being 'in buffer' waiting to be flushed to disk, but in drbd memory, > > correct? > > _______________________________________________ > > drbd-user mailing list > > drbd-user at lists.linbit.com > > http://lists.linbit.com/mailman/listinfo/drbd-user > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBDR and LINBITR are registered trademarks of LINBIT, Austria. > __ > please don't Cc me, but send to list -- I'm subscribed > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user