Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Sep 21, 2012 at 7:51 AM, Felix Frank <ff at mpexnet.de> wrote: > Hi, > > the scenario is really very common and requires no action aside from > those documented everywhere. > > On 09/21/2012 04:17 PM, Lonni J Friedman wrote: >> I'm trying to do a proof of concept, in which I was attempting to >> synthetically simulate the failure of the primary. I did this by >> bringing down the network interface on the primary. Prior to doing >> that, drbd-overview reported everything as being in sync >> (UpToDate/UpToDate). > > Then after pulling the plug - what does drbd-overview tell you now? > What's your local disk state (on the secondary)? > > I suspect it's no longer UpToDate. If you wonder why it's not, please > examine the kernel logs on your secondary. All state changes are usually > logged and explained. Fell free to share them if they are not helpful on > their own. I suspect you're right. I think what happened is that I was fumbling around through different drbdadm commands in an attempt to find the right combination & ordering to get this working, and likely made a huge mess of things. This time, I took special care to note exactly what I was doing, and I believe that I've found a series of steps that does the right thing: drbdadm primary r0 # run on secondary to promote to primary drbdadm secondary r0 # run on (original) primary to demote to secondary drbdadm invalidate r0 # run on (new) secondary drbdadm connect r0 # run on (new) secondary At least, that has accomplished what I was trying to do all along, and everything currently reports as UpToDate/UpToDate.