Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Cc: "Montrose, Ernest" <Ernest.Montrose@stratus.com>
Subject: Re: [Drbd-dev] DRBD8: Split-brain if primary and syncTarget
Date: Mon, 12 Mar 2007 15:28:20 +0100	[thread overview]
Message-ID: <200703121528.20523.philipp.reisner@linbit.com> (raw)
In-Reply-To: <BD7042533C2F8943A6A4257A9E31C45439C91C@EXNA.corp.stratus.com>

Am Donnerstag, 8. März 2007 23:21 schrieb Montrose, Ernest:
> Hi all,
>
> We are seeing an issue with split brain if one node is syncing as
> syncTarget while being Primary.
> two node A and B.
> * make B primary and the syncTarget
> * Start a sync.
> * ifdown eth1 to break communication
> * ifup eth1.
> * then on the node in standalone "drbdadm connect"
> We get a split-brain.
>
> I think the  problem is that if we are primary and we lose contact from
> the other side we generate a new current UUID which causes a Split-Brain
> next time we connect.
> This only happens if we are the sync target and we are primary. Perhaps
> we should not generate a UUID if we were syncing when the disconnect
> happen. Below is a possible patch for this in after_state_ch():

Hi Ernest,

I think the current behaviour is correct.

* When a node is SyncTarget it actually exposes the data of the sync
  source node to its applications. (And the applications can potentially 
  see the data when the SyncTarget node is primary.)

* When you disconnect such a node, it has to fall back to its local
  data set. == suddenly the applications see a different data set,
  and of course the apps might continue to modify this data set...

* Wen you reconnect this, you have a split brain situation. But you 
  might let the automatic-split-brain resolving handler solve the
  situation. Use some after-sb-?pri settings, and an rr-conflict of
  "violently" E.g.:

  after-sb-0pri discard-least-changes
  after-sb-1pri violently-as0p
  after-sb-2pri violently-as0p
  rr-conflict   violently

  Then the resync should continue. Since the "violently" allows DRBD
  to change the data set again, that is seen on the Primary node.

-Phil
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Vivenotgasse 48, 1120 Vienna, Austria        http://www.linbit.com :

  parent reply	other threads:[~2007-03-12 14:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 22:21 [Drbd-dev] DRBD8: Split-brain if primary and syncTarget Montrose, Ernest
2007-03-12 14:02 ` Goswin von Brederlow
2007-03-12 14:28 ` Philipp Reisner [this message]
2007-03-12 14:52   ` Philipp Reisner
  -- strict thread matches above, loose matches on Subject: below --
2007-03-12 14:36 Montrose, Ernest
2007-03-12 15:35 Montrose, Ernest
2007-03-13 10:23 ` Philipp Reisner
2007-03-13 13:51 Montrose, Ernest

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703121528.20523.philipp.reisner@linbit.com \
    --to=philipp.reisner@linbit.com \
    --cc=Ernest.Montrose@stratus.com \
    --cc=drbd-dev@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox