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, Jan 10, 2017 at 02:16:41PM +0000, Per Sundström XP wrote: > Bumping this thread. > Anybody knows if the behavior we see is a bug or a feature ?? > To me it looks like a bug. If I understand your scenario correctly, you have NOT allowed multiple primaries (allow-two-primaries no;) You disconnect the peers, you make both primary while they cannot communicate, and cause data divergence. You then connect them again while both are primary. They refuse to connect, because they see multiple primaries, and that is not allowed by the configuration. If that is indeed your scenario, it "works as designed", and I think is the same behaviour with 8.4. If 9.0.6 behaves differently, we need to look into that. Also note that DRBD 9 fencing policies do not yet work properly and show all sorts of strange behaviour. We are working on that. > From: Per Sundström XP > Sent: den 2 januari 2017 17:21 > To: 'drbd-user at lists.linbit.com' <drbd-user at lists.linbit.com> > Subject: v9.0: Node does not go into StandAlone on two primary split brain > > Hi, > > We have been using DRBD V8 and are in the process of moving to V9. > To be exact: "version: 9.0.1-1 (api:2/proto:86-111) GIT-hash: > 86e443973082570aeb651848db89e0c7b995c306 build by abuild)" No. Really. When reporting "bad" behaviour, please first reproduce using "latest". > One difference that we see is that if configured with > "allow-two-primaries no" and when there is a network disconnect that > ends up in two [disconnected] primaries neither of them will go into > "StandAlone" connection state when the network is reconnected. > > Instead both nodes stay in state "Connecting" and refuses to connect > with the error: "Multiple primaries not allowed by config" Due to > this, the disk state is never compared and no split brain logic is > triggered. > > Is this a bug or a feature with V9 ? > If this is expected behaviour, what is the new way of detecting that > we have two primaries ? One [hackish] workaround is to dynamically > temporarily allow two primaries while in state "Connecting" but that > does not feel right. > > /Per > > The V9 documentation has this in it: > > > "DRBD detects split brain at the time connectivity becomes available > again and the peer nodes exchange the initial DRBD protocol handshake. > If DRBD detects that both nodes are (or were at some point, while > disconnected) in the primary role, it immediately tears down the > replication connection. The tell-tale sign of this is a message like > the following appearing in the system log: > Split-Brain detected, dropping connection! > After split brain has been detected, one node will always have the > resource in a StandAlone connection state. The other might either also > be in the StandAlone state (if both nodes detected the split brain > simultaneously), or in WFConnection (if the peer tore down the > connection before the other node had a chance to detect split brain)." -- : Lars Ellenberg : LINBIT | Keeping the Digital World Running : DRBD -- Heartbeat -- Corosync -- Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT __ please don't Cc me, but send to list -- I'm subscribed