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