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>