Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi All: I am hitting a strange behavior during truck replication (so far it has occurred to one machine out of 10). I have two machines node1 and node2, and I am restoring metadata on node2. Whenever I do the following (as mentioned on truck replication page) resynchronization takes place. Any idea what could be causing this, any clues to debug such issues? drbdsetup 1 new-current-uuid --clear-bitmap drbdadm detach res drbdmeta_cmd=$(drbdadm -d dump-md res) drbdadm detach res ${drbdmeta_cmd/dump-md/restore-md} /var/testmeta 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]). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ version: 8.3.4 (api:88/proto:86-91) GIT-hash: 70a645ae080411c87b4482a135847d69dc90a6a2 build by rmake-chroot at localhost.localdomain, 2009-10-27 15:57:44 1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r---- ns:0 nr:9735808 dw:9731552 dr:0 al:0 bm:592 lo:135 pe:29068 ua:133 ap:0 ep:1 wo:b oos:2668488204 [>....................] sync'ed: 0.4% (2605944/2615448)M finish: 62:56:09 speed: 11,768 (11,460) K/sec From: tech_j at hotmail.com To: lars.ellenberg at linbit.com; drbd-user at lists.linbit.com Date: Mon, 2 Nov 2009 19:29:01 +0000 Subject: Re: [DRBD-user] Truck replication Thats correct. The problem was with my perception of how it suppose to work versus the actual behavior. Truck based replication worked perfectly for me. After initial UpToDate/UpToDate message I untared the my directory structure on drbd mounted device and monitored dw (disk write) status from which I was able to see disk writes happening. Before this I was hoping to see UpToDate/Inconsistent(or Outdated) ds message, but that was just my perception. Thanks a lot for help. Regards, Jay > Date: Sat, 31 Oct 2009 10:17:22 +0100 > From: lars.ellenberg at linbit.com > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] Truck replication > > On Thu, Oct 29, 2009 at 07:41:16PM +0000, jay b wrote: > > > > Hi All: > > > > I am stuck with truck based replication. I have the following setup: > > > > node1 (primary): > > /dev/sda7 [4TB] > > /dev/drbd1 > > I have also created filesystem ext3 on drbd1 > > > > node2: > > <same configuration as above, but there is NO filesystem> > > > > I am basically trying to avoid the initial sync time (if possible). > > So, now node1 is primary and if I follow steps written on this page > > http://www.drbd.org/users-guide/s-using-truck-based-replication.html > > I can get both servers to display uptodate/uptodate state. > > > > But, when I mount /dev/drbd1 to /mnt/drbd (on node1 which is primary), > > and copy files to /mnt/drbd, I do not see Uptodate/Inconsistent > > message (via cat /proc/drbd on node1) > > Why would you expect node2 to become "Inconsistent" > during normal operation? > > > At this point I would assume that node2 should get some data and try > > to sync with primary. Am I missing any steps? > > When you _connect_ the second node, > it will do some (bitmap based) resync. > > Once connected, and "Connected Uptodate", > it will do _online replication_. > > If there is problem, I don't see it? > Either you or me or DRBD misunderstood something, I guess. > > -- > : 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 Save up to 84% on Windows 7 until Jan 3-eligible CDN College or University students only. Hurry-buy it now for $39.99! _________________________________________________________________ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://go.microsoft.com/?linkid=9691817 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20091109/956380ef/attachment.htm>