Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> It happened again. Here is what I did: > > 1. on node B: > drbdadm secondary resource Why did you do this? was the resource in Primary state? > drbdadm -- --discard-my-data connect resource > > 2. on node A > drbdadm connect resource > > Then everything was fine again. node A was primary, node B was secondary. Are you sure node A drbd5 is Primary/Secondary UpToDate/UpToDate before you shut down B? Your symptoms sound like A might have been Primary/Secondary diskless/UpToDate or something else. If you could repeat your test (or infer it from the logs) it would be helpful to see the status between each step from both nodes starting before the shutdown of B. > > Then I shut down node B. > > Then I rebooted node A. > > Then, one resource on node A came up as primary without the problems. > The second resource on node A (the one which I had to resolve from split > brain) again did not come up: > > block drbd5: State change failed: Refusing to be Primary without at least one UpToDate disk > > The I tried to force it to primary: > > # drbdadm -- --overwrite-data-of-peer primary cc-manager-templates-ha > 5: State change failed: (-2) Refusing to be Primary without at least one UpToDate disk > > Any ideas what is happening here? Dan, in Atlanta