[DRBD-user] Version issue? - DRBD Primary on 8.3.2 - Secondary on 8.3.13

Florian Haas florian at hastexo.com
Mon Oct 8 08:41:14 CEST 2012

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


On Sun, Oct 7, 2012 at 6:56 PM, ShockwaveCS <shockwavecs at gmail.com> wrote:
>
> Can I downgrade the secondary host back to 8.3.2 without any negative side
> effects? -Or- Can I upgrade the 8.3.2 to 8.3.13 while the node is online,
> serving data, and still Primary? Doesn't seem likely, but hey why not ask. I
> want to do one of these because of the scenario below:
>
> Note: Split-Brain does not appear in logs on either node.
>
> I have an issue with our DRBD setup. I upgraded the Secondary host to 8.3.13
> during an upgrade of the host. When syncing the devices everything looks to
> be OK and UpToDate. Upon a reboot of the system, 2 of the resources act like
> split brain:
>
> Primary:
> 0:r0   Connected     Primary/Secondary  UpToDate/UpToDate  C
> 1:r1   WFConnection  Primary/Unknown    UpToDate/DUnknown  C
> 2:r2   Connected     Primary/Secondary  UpToDate/UpToDate  C
> 3:r3   WFConnection  Primary/Unknown    UpToDate/DUnknown  C
> 4:r4   Connected     Primary/Secondary  UpToDate/UpToDate  C
> 5:r5   Connected     Primary/Secondary  UpToDate/UpToDate  C
>
>
> Secondary:
> 0:r0   Connected   Secondary/Primary  UpToDate/UpToDate  C
> 1:r1   StandAlone  Secondary/Unknown  UpToDate/DUnknown  r-----
> 2:r2   Connected   Secondary/Primary  UpToDate/UpToDate  C
> 3:r3   StandAlone  Secondary/Unknown  UpToDate/DUnknown  r-----
> 4:r4   Connected   Secondary/Primary  UpToDate/UpToDate  C
> 5:r5   Connected   Secondary/Primary  UpToDate/UpToDate  C
>
> in the logs I see:
> Secondary:
> Oct  6 02:32:53  kernel: block drbd1: self
> F706B62542107DA8:0000000000000000:1C07F1C6CA998612:D56E6E590DC60A6B bits:0
> flags:0
> Oct  6 02:32:53  kernel: block drbd1: peer
> F706B62542107DA9:1C07F1C6CA998613:D56E6E590DC60A6B:23CC2F9D13ACE404
> bits:492137 flags:0
> Oct  6 02:32:53  kernel: block drbd1: uuid_compare()=-1091 by rule 30
> Oct  6 02:32:53  kernel: block drbd1: To resolve this both sides have to
> support at least protocol 91
> Oct  6 02:32:53  kernel: block drbd1: conn( WFReportParams -> Disconnecting
> )
> Oct  6 02:32:53  kernel: block drbd1: error receiving ReportState, l: 4!
> Oct  6 02:32:53  kernel: block drbd1: asender terminated
> Oct  6 02:32:53  kernel: block drbd1: Terminating asender thread
> Oct  6 02:32:53  kernel: block drbd1: Connection closed
> Oct  6 02:32:53  kernel: block drbd1: conn( Disconnecting -> StandAlone )
>
>
> So it appears to not want to establish a link based on protocol version.
> Fine. Let's roll back to Protocol 90? Hmm. Possible?

Um. Well normally the contract is that you should be able to up- and
downgrade between point releases at will -- just so long as you don't
use enable any features present in the new release and absent in the
old, which is quite logical. However, I suppose you didn't change your
configuration at all in the interim, so this shouldn't be happening.
Regardless, if you could pastebin your config and share the link here,
then that would be helpful.

Lars, did any _default_ settings change in 8.3.3, when proto 91 was introduced?

Cheers,
Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now



More information about the drbd-user mailing list