Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Feb 27, 2009 at 12:45:08AM +0800, leishou yu wrote: > Hi list, > I have a cluster with two nodes based on DRBD 0.7.24. > > Node1 <---------------------------------------> Node2 > (Active) (Protocol C) (inActive) > > The scenario of my test case is: > Step 1. When a write request to the Node1 arrives, Node1 transfers the > request to the local disk driver and the peer. > Step 2. Suppose the Node2 receives the data packets and writes to its local > disk completely, but the corresponding action is delayed in Node1( maybe > for some random reasons). > Step 3. At that very moment, Node1 is powered -off unexceptedly; the data > waiting in the buffer is lost. > Step 4. The cluster manager promotes Node 2 from secondary to primary. > Step 5. Node 1 is powered-on again. > > So, the Node 2 has more on-disk data than Node 1. > My question is: > 1) Will Node 2 just make a backgroud resync to Node 1 for that unfinished > write request? or scenario as described above: node2 has taken over in step 4. node1 comes back as secondary after reboot, reconnects, and becomes SyncTarget. > 2) Node 1 makes Node 2 to drop the result of that unfinished write request > (Node 1 resync Node 2)? as node2 has taken over in step 4, and probably changed (a lot of) data since node1 went down, that would be wrong and stupid. if, however, node2 does nothing but sit there, staying secondary, waiting for node1 all the time, then yes, node1 would become SyncSource, and "undo" that unfinished request. but. IT DOES NOT MATTER. why? because that request was not completed to upper layers. so it was "in flight". if you have a single node, and there is a write request "in flight", and it crashes, before that write request is completed, you do not know if it made it to non-volatile cache or rotating rust, or not. ACID "compliant" applications can deal with crashes, and do crash recovery. other applications do not. in short: if your application can recover from a single node crash, it can recover from a drbd protocol C primary node crash. if not, well, sorry, but that is not DRBDs fault. -- : 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