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