Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Robert, On 2008-11-12 11:12, Robert Heinzmann (ml) wrote: > Note: This is a english re-post of "Versehentliches "drbdadm invalidate > XXX" rückgängig machen ? " > > Hello list, > > I have a question regarding UNDO of the "drbdadm invalidate" command > (prior to sync). > > We have a cluster of 2 machines, DRBD 8.2.6 and we had a split brain. > The filesystem was active on both nodes - NodeA and NodeB. > > We did the following: > > - Thought NodeA had the latest data > - drbdadm secondary on NodeB > - drbdadm invalidate on NodeB Wrong approach to resolve split brain, even if you _had_ identified the nodes correctly. Should have followed http://www.drbd.org/users-guide/s-manual-split-brain-recovery.html > now we found that NodeB had the latest data. We did not issue "connect" > yet, so no data changed (only meta data) > > /proc/drbd: > > version: 8.2.6 (api:88/proto:86-88) > ... > 1: cs:StandAlone st:Secondary/Unknown ds:Inconsistent/DUnknown ra-- > ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:58562364 > > GI: > 7A0A55CE55896BFE:0000000000000000:DB3807ED2AF2EC64:83495FFABA3A0737:0:0:0:0:0:0 > > > > How can I undo the "invalidate" command, so that I can change the resync > direction afterwards ? > > The goal is to get back to the split brain situation, so hat I can issue > "invalidate" on the other node (NodeA). > > I guess it's drbdmeta set-gi, however I tried ::::1:0:0:0:0:0 and > ::::0:1:0:0:0:0, did not help. > > I also guess it's setting back the 00000000 above to a common parent GID > (GID2 on the other node ?), but I would need some clarification :) You've already maneuvered yourself into a situation where you need a full sync to recover (the correct approach, described in the User's Guide, does not trigger a full resync). So rather than fiddling with the generation identifiers, why don't you nuke your metadata (drbdadm down, drbdadm create-md) on both nodes, and start from scratch using --overwrite-data-of-peer? Yes there is a (much more deeply involved) way to recover the quick-sync bitmap and reset the generation identifiers in your situation, but I probably wouldn't bother if I were you. So reinitialize the metadata and start over. Florian -- : Florian G. Haas : LINBIT Information Technologies GmbH : Vivenotgasse 48, A-1120 Vienna, Austria When replying, there is no need to CC my personal address. I monitor the list on a daily basis. Thank you. DRBD® and LINBIT® are registered trademarks of LINBIT.