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, Mar 09, 2010 at 02:47:29AM -0800, avn wrote: > > OK, > You may have a point here. > > > On Tue, Mar 09, 2010 at 01:53:20AM -0800, avn wrote: > > >> after-sb-0pri discard-younger-primary; > > This should be the line with potential danger to new data. > > >> after-sb-1pri violently-as0p; > But I think my situation has nothing to do with it. The primary goes down > and stay down. > My expected behaviour is that the slave should become primary, and being > synced with the older primary should have the data ( the modified file just > before sending down initial master) in order.This is not happening and this > is the issue. And yes, when the down server comes up the line above is > executed and all new data written on the surviving server should be lost (my > intention indeed). > Am I wrong? - primary crash - secondary takes over - former primary returns and syncs up is a perfectly normal and expected sequence of events in a DRBD cluster. In fact, that is the sequence of events DRBD was primarily designed to cope with. No need for anything special. If that is not working for you, your setup is broken. No "split brain" anywhere, so you won't need any of those auto resolve policies. If you _do_ need those policies to get them connected again, you had data divergence before that crash, you have not been connected. Please verify that you are Connected UpToDate/UpToDate before the "crash" of the Primary. And, btw, you need to _subscribe_ to this list, or wait for a moderator to manually let your posts through. -- : 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