Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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). >From the local consistency point of view, replication protocols do not make a difference. To the file system and application, the data just looks like the node crashed between updates X and Y. If your file system or application is not crash safe, DRBD cannot magically make it so, no matter what, regardless of replication protocol. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed