[DRBD-user] Switching from internal to external meta-disk

Lars Ellenberg lars.ellenberg at linbit.com
Wed Jul 11 21:24:44 CEST 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Tue, Jul 10, 2012 at 06:59:36PM +0200, Jean-Baptiste wrote:
> Hello,
> 
> Today I was confronted with this problem :
> 
> I've got a 2 nodes cluster. Both of them uses drbd resource to assume
> failover.
> The main drbd resource store all the data of an Oracle SGBD.
> 
> To solve my problematic (frequently resize resources), I decided to move
> the drbd metadatas from internal to external volume.
> 
> The sub-layer used is LVM.
> Here is how I was do this :
> 

The starting point is missing.

Have the peers been "Connected UpToDate/UpToDate" ?

>    1. Create new logical volume to store meta-datas
>    2. Unmount the resource to migrate
>    3. Dump the meta-datas to plain file
>    4. Shutdown the resource (drbdadm down <RES>)
>    5. Modify the drbd.conf to use meta-disk external
>    6. Restart drbd daemon

uhm. there is no drbd "daemon" ... but anyways...

>    7. Create md for the resource (drbdadm create-md <RES>)

I don't see the step where you restore the previously dumped meta data?

>    8. Startup resource

So in 7. you told DRBD that it was a fresh "just created" instance,
without any valid data.

If by "startup resource" you mean "drbdadm up <resource>" (or adjust),
it will connect to the peer, which *does* have valid meta data,
so immediate full sync is started right here, from the peer
to the node where you did "create-md".

>    9. Doing drbdadm -- --overwrite-data-of-peer primary <RES> (from the
>    primary node)

Well, of course you can promote a SyncTarget to Primary,
as it has access to the peers data.
But the "--overwrite-data-of-peer" is actually a "--force",
and only relevant if DRBD otherwise would have refused to promote.
Which in this case, it likely would not have, anyways.

>    10. Let synchronize process ending

Without noticing that it was not the expected direction.


>    11. Done
> 
> At this step everything is fine, my SGBD was restarted without any warning,
> nothing seems to go wrong.
> But ... I was lost 11 days of data in my SGBD.
> 
> I'm disapointed, does anyone have an idea about this ?
> At least to explain this.
> 
> Thanks



-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com



More information about the drbd-user mailing list