[DRBD-user] Undo "drbdadm invalidate xxxx" ?

Florian Haas florian.haas at linbit.com
Wed Nov 12 12:08:01 CET 2008

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.



More information about the drbd-user mailing list