Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I'm using a logic volume as drbd's underlying device ( /dev/lvmdatas/db for /dev/drbd1 ), with `before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 5 -- -c 16k";' and `after-resync-target /usr/libdrbd/unsnapshot-resync-target-lm.sh;' in drbd.conf. Consider the following scenario: nodeA (Primary) and nodeB (Secondary) were disconnected at first, and their dist state were "UpToDate/Outdated" When I connect the connect two nodes, nodeB will create the snapshot `/dev/lvmdatas/db-lbefore-resync', which will be delete after resync complete, and everthing will be fine. But what if the the NodeA crash during the resync, now the /dev/drbd1 odr /dev/lvmdatas/db have the Inconsistent data, while /dev/lvmdats/db-before-snyc have the consistent, but outdated data. I would like to revcery the /dev/lvmdatas/db from /dev/lvmdats/db-before-snyc and then bring up the database. However, drbd is above the logic volume, my problem was: how should I recovery the /dev/lvmdatas/db from snapshot, without breaking up drbd metadata? On Sat, Aug 27, 2011 at 2:28 AM, Dan Barker <dbarker at visioncomm.net> wrote: > > Reading between the lines on this thread, I think you have mixed access paths, and now believe that drbd is somehow involved in your troubles. > > It is perfectly correct to do what you attempted, IE: Break the mirror, test some process, reestablish the mirror using the original data, and continue on. > > Assuming the drbd resource r0 as /dev/drbd0, stored on /dev/sdb1 on nodeA (Primary) and nodeB (Secondary): > > This scenario would be accomplished by: > > On NodeB: > ========= > drbdadm disconnect r0 > drbdadm primary r0 > mount /somewhere /dev/drbd0 > > ... do your test on nodeB ... > > umount /dev/drbd0 > drbdadm secondary r0 > drbdadm -- --discard-my-data connect r0 > > and the nodes will sync up to the original data. The main node, nodeA always has the resource as primary, and goes from Connected to WFConnection to SyncSource to Connected. No access to the physical device, /dev/sdb1 is done by any process other than drbd. You never stop drbd on either node. > > I'm guessing that at some point you mounted /dev/sdb1 instead of /dev/drbd0 and that is the source of your problems; Updates occurred that drbd did not see. Using the full disk rather than a partition (/dev/sdb instead of /dev/sdb1 in this case) could assist in preventing you from shooting yourself in the foot. But, you can ALWAYS shoot yourself in the foot. > > I do not understand your comment "I shut down drbd, try to use rsync to recovery the snapshot, but failed" It sounds like there is a Logical Volume Manager involved, or some other underlying block device that supports snapshots. > > Again, drbd can only replicate changes to a block device that occur while drbd is handling that device. The observations above can be applied to any block device. If you expect drbd to be able to handle the block device, it must be the only access to that device; Connected or not, Primary or Secondary. > > hth > > Dan Barker > > -----Original Message----- > From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Arnold Krille > Sent: Friday, August 26, 2011 2:08 PM > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] data integrity in drbd > > On Friday 26 August 2011 19:50:29 you wrote: > > In my situation, what should I do to completely resync the data of > > secondary node, including the drbd metadata ? > > Delete the secondaries disk, create the meta-data anew and make it sync completely from the primary. And if something is still wrong in the files on disk, restore them from the backup... > > (And don't ask public questions in private:) > > Have a nice weekend, > > Arnold > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user