[DRBD-user] Truck replication

jay b tech_j at hotmail.com
Wed Nov 18 17:52:17 CET 2009

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


> Then how about the approach documented in the man page?
> http://www.drbd.org/users-guide/re-drbdsetup.html

That
approach is working perfectly, except for one set of boxes that have
with exactly same hardware configuration. And I just want to figure out
why it is behaving in this manner on these boxes.  Okay, let me explain
what I've been doing

config:
~~~~
global {
        usage-count yes;
}
common {
        protocol C;
        startup {
                wfc-timeout 120;
                degr-wfc-timeout 120;
        }
}
resource my_res {
        syncer {
                rate 333M;
        }
        on node1 {
                device /dev/drbd1;
                disk /dev/sdb3;
                address 192.168.2.1:7791;
                meta-disk internal;
        }
        on node2 {
                device /dev/drbd1;
                disk /dev/sdb3;
                address 192.168.2.2:7791;
                meta-disk internal;
        }
}

node1 (primary)
~~~~~~~~~
- drbdadm create-md my_res
- drbdadm up my_res
- drbdadm disconnect my_res (because new-current-uuid would occur only on "standalone")
- drbdsetup 1 new-current-uuid --clear-bitmap
- drbdadm new-current-uuid my_res
- drbdadm detach my_res (because I need to produce and primary dump and I cannot do this if resource is attached)
- drbdadm dump-md my_res > primary_dump
- scp this "primary_dump" to node2

node2 (secondary)
~~~~~~~~~~~
- drbdsetup 1 new-current-uuid --clear-bitmap
- drbdmeta 1 /dev/sdb3 internal restore-md primary_dump

On both nodes:
~~~~~~~~~
- drbdadm adjust all

At this point both nodes are connected with "Secondary/Secondary Inconsistent/Inconsistent" state

Make node1 primary:
~~~~~~~~~~~~
drbdadm -- --overwrite-data-of-peer primary my_res

*
Now at this point I would expect both nodes to be in "Primary/Secondary
UpToDate/UpToDate" state, but they are not. Instead the state is
"Primary/Secondary UpToDate/Inconsistent" state and displaying
[=>...........] sync'ed:0.01% message.

I have successfully
tested this procedure on 10 other boxes and I have had no issue, except
for this one box.  So, I am trying to find out more about this behavior
and under what circumstances it may occur.  I'd greatly appreciate any
help on this behaviour.

Here is dmesg output:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
block drbd1: conn( Unconnected -> WFConnection ) 
block drbd1: Handshake successful: Agreed network protocol version 91
block drbd1: conn( WFConnection -> WFReportParams ) 
block drbd1: Starting asender thread (from drbd1_receiver [24837])
block drbd1: data-integrity-alg: <not-used>
block drbd1: drbd_sync_handshake:
block drbd1: self C48D0F6F05011D66:02D67DD221F19CD8:0000000000000004:0000000000000000 bits:669554939 flags:0
block drbd1: peer C48D0F6F05011D66:02D67DD221F19CD8:0000000000000004:0000000000000000 bits:0 flags:0
block drbd1: uuid_compare()=0 by rule 40
block drbd1: No resync, but 669554939 bits in bitmap!
block drbd1: peer( Unknown -> Secondary ) conn( WFReportParams -> Connected ) pdsk( DUnknown -> Inconsistent ) 
block drbd1: peer( Secondary -> Primary ) pdsk( Inconsistent -> UpToDate ) 
block drbd1: drbd_sync_handshake:
block drbd1: self C48D0F6F05011D66:02D67DD221F19CD8:0000000000000004:0000000000000000 bits:669554939 flags:0
block drbd1: peer 40BD0C3BDCF22CB9:C48D0F6F05011D66:0000000000000004:0000000000000000 bits:0 flags:0
block drbd1: uuid_compare()=-1 by rule 50
block drbd1: Becoming sync target due to disk states.
block drbd1: conn( Connected -> WFBitMapT ) 
block drbd1: conn( WFBitMapT -> WFSyncUUID ) 
block drbd1: helper command: /sbin/drbdadm before-resync-target minor-1
block drbd1: helper command: /sbin/drbdadm before-resync-target minor-1 exit code 0 (0x0)
block drbd1: conn( WFSyncUUID -> SyncTarget ) 
block drbd1: Began resync as SyncTarget (will sync 2678219756 KB [669554939 bits set]).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Regards,
-Jay

> Date: Wed, 11 Nov 2009 10:22:10 +0100
> From: lars.ellenberg at linbit.com
> To: drbd-user at lists.linbit.com
> Subject: Re: [DRBD-user] Truck replication
> 
> On Tue, Nov 10, 2009 at 07:18:16PM +0000, jay b wrote:
> > 
> > 
> > Truck replication page: http://www.drbd.org/users-guide/users-guide.html 
> > For dump /restore part: http://www.drbd.org/users-guide/s-resizing.html 
> > 
> > What I am trying to achieve:
> 
> ...
> 
> > I want to avoid initial sync time,
> > which in our case takes more than 12hrs.
> 
> Right.
> 
> Then how about the approach documented in the man page?
> http://www.drbd.org/users-guide/re-drbdsetup.html
> 
> Currently the sub section on "new-current-uuid" is
> http://www.drbd.org/users-guide/re-drbdsetup.html#id1229962
> 
> But those id anchors are likely to change on future updates,
> so if someone digs this from an archive,
> just "find" the heading/subsection on "new-current-uuid".
> 
> 
> -- 
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> __
> please don't Cc me, but send to list   --   I'm subscribed
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
 		 	   		  
_________________________________________________________________
Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7 now
http://go.microsoft.com/?linkid=9691818
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20091118/953d2ec2/attachment.htm>


More information about the drbd-user mailing list