[DRBD-user] secondary sync behaviour after drbd stop and start

Lars Ellenberg lars.ellenberg at linbit.com
Wed Jun 22 09:58:46 CEST 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Wed, Jun 22, 2011 at 09:41:27AM +0200, Felix Frank wrote:
> Hi,
> On 06/22/2011 08:29 AM, Gianluca Cecchi wrote:
> > Certainly it is not my intention to bypass DRBD. In fact in my e-mail
> yet that is what you inadvertantly did. DRBD has no possible way of
> finding out that you messed with its backing storage. Well, except you
> do an online verify, which is expensive.
> > I tried to clarify that it was a simulation of changed data before
> > resync.
> This can happen if the "remote" side becomes Primary while disconnected.
> The result is a split-brain, which must be resolved one way or another
> (usually by human intervention - you get to decide whose changes should
> get trashed). See
> http://www.drbd.org/users-guide/s-resolve-split-brain.html.
> Again: If someone decides to mess with DRBD *backing storage*, chances
> are it will never be detected unless you run verify.
> > b)
> > drbdadm invalidate-remote r0
> Sure, fencing your peer is a way of safe-guarding yourself against
> split-brain.

Though the statement in itself is correct,
"invalidate-remote" has NOTHING to do with fencing.

: 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

More information about the drbd-user mailing list