[DRBD-user] Write order

Lars Ellenberg lars.ellenberg at linbit.com
Tue Jun 14 20:39:20 CEST 2011


On Tue, Jun 14, 2011 at 11:07:38AM -0700, LangTuSJ wrote:
> 
> Hi Lars,
> 
> Thanks very much for your reply.  I'm not sure if I understand your answer
> to 2nd part of my question so allow me further clarify what I meant.
> 
> In case of DR, my primary server on Site 1 will be completely dead and
> there's no way for me to access to it so I have to use what I currently have
> on my secondary server on Site 2.  Now my main concern is the disaster
> happened right in the middle of replicating.

Well, yes, it usually does ;-)

> DRBD was supposed to write 4
> blocks of disk from Site 1 to Site 2 but it just completed 2 blocks.  If
> this is using Protocol C, then I would not have any problem since it follows
> "all-or-nothing" rule but I'm using Protocol A here.  My application on Site
> 2 wouldn't be started since it got incomplete fragment of data.

If your application is really not crash safe,
see the last paragraph in this mail.

> Unless DRBD
> is smart enough to know that it gets disconnected in the middle and rolls
> back that two blocks of disk, I'm very much in a messy state.  Does DRBD
> provide a way to deal with this kind of out-of-sync, corrupted state?

No.
And it does not need to.
Because this is in no way corrupted.

Application submits these updates: X, Y, Z.
They may or may not be to the same block.
If they are to the same block, then the application, file system
or other layer already makes sure (or at least is supposed to do that),
that the first update will finish before the second is submitted.

These updates are replicated to the peer.

They reach the peer, or they don't.

For the consistency of the data on the peer, it does not make a
difference whether protocol A, B, or C was used:
if only update X makes it to the peer,
but Y and Z does not, then they are missing from the peer's copy.

The difference with drbd protocols A and C is only whether there may
be something missing, which had previously been "confirmed" as being 
"on stable storage" to some external entity (e.g. data base client).



More information about the drbd-user mailing list