[DRBD-user] strange split-brain problem

Klaus Darilion klaus.mailinglists at pernau.at
Tue Dec 7 20:56:09 CET 2010

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



Am 07.12.2010 20:43, schrieb Lars Ellenberg:
> On Tue, Dec 07, 2010 at 08:36:01PM +0100, Klaus Darilion wrote:
>> Hi Lars!
>
>>>> Then some more reboots on node A and suddenly:
>>>>
>>>> block drbd5: State change failed: Refusing to be Primary without at
>>>> least one UpToDate disk
>>>> block drbd5:   state = { cs:WFConnection ro:Secondary/Unknown
>>>> ds:Diskless/DUnknown r--- }
>>>       ^^^^^^^^
>>>
>>> You failed to attach, you have not yet connected,
>>> so DRBD refuses to become Primary: which data should it be Primary with?
>>
>> but how can it be secondary without and disk?
>
> Oh the wonders of DRBD ;-)
> Well, you told it to.
> It's completely legal to tell a DRBD to connect to its peer
> without having a local disk attached.  It's unusual, though.
>
>>
>>>> Then the status on node A was:
>>>>
>>>> cc-manager-templates-ha  Connected Primary/Secondary
>>>> Diskless/UpToDate A r----
>>>
>>> It was able to establish the connection,
>>> and was going Primary with the data of the peer.
>>
>> Is this a feature? How can it know that the peers data is up2date
>> when it can not attach to the local disk?
>
> You told it to.  DRBD typically does what it is told,
> unless it happens know better for sure
> (and even then you can force it, usually).
>
> If you tell it to connect without first attaching a local disk,
> and you don't have resource level fencing mechanisms in place
> so the remote end assumes itself to be uptodate,
> that's your problem.

Ouch.

Thanks for the explanations.

regards
Klaus



More information about the drbd-user mailing list