Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 24, 2011 at 02:24:16AM +0800, jayson.cena at teamglac.com wrote: > but only vmcluster02 is writing to r0 > because the startup configuration of > the VM that is using r0 will only reside on 1 host. Then the other should not have been made Primary. > is there a possibility that when the hosts writing to the resource > crashed, a split brain will occur? "split brain" in this context is defined as situation where both nodes have been in Primary role without communicating with the peer. Not necessarily at the same time, but during the same time period without communication. The "split brain" is detected on the next handshake by means of the data generation uuids. If they diverge, DRBD has to assume that data _could_ have been modified independently. There is only one "safe" (in some sense) auto-recovery strategy, and that is "discard-zero-changes", where zero changes means DRBD is _sure_ that there have not been any changes. As soon as DRBD has some doubt about whether or not there could have been changes, it needs to throw away potentially changed data. And you should be pretty sure that you mean it if you configure it to throw away data _automatically_. If you tell DRBD to throw away your data, don't blame DRBD if it does just that. -- : 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