Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thanks Felix, > > The resource nodes are still disconnected and no override has been > > used to force the situation. > > The only commands issued have been drbdadm connect all, drbdadm > > connect x2, drbdadm primary x2 (on the only node that has ever been > > primary) and drbd attach. > > I'm the only one with access to these machines, I can assure you > > sync has not been forced at any time. > > > > The only log record against this resource in all archived messages > > prior to the system restart is.. > > Jan 11 11:30:31 emlsurit-v4 kernel: [7745016.672246] block drbd9: > > disk( UpToDate -> Diskless ) > > I expect this is the point at which the drbdadm detach was issued, > > while the node was primary and active. > > Holy shit. Now this is a useful piece of information. > > You made your Primary diskless 12 days before you aleged DRBD problem. > This of course leads to all writes being done on the Secondary (you're > in a degraded state). > > This is all fine except after reboot, you made your main node (the one > that's been diskless for a couple of days) Primary again before the > handshake took place. Hence split-brain. > > > From the command history I can't determine which node the detach was > > issued from. > > The one that went diskless. Detach is a local operation and doesn't > affect the peer. > > > Does it matter which node a drbdadm detach is issued from? > > Yes, it's essential. Cringe... Thanks for clearing this up, it's all making perfect sense. I'm glad to have learned my lesson at this point rather than down the road. Sorry to have taxed your time in getting here. Lew