Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, I suspect there are some misconceptions on your part. If you take an image from the remote part of a three-node cluster, you truck-based initiate the *stacked* device, nothing else. Your lower DRBD is somewhat larger than the stacked device, as it needs to contain an additional set of metadata. After freshly initializing the lower DRBD, the resulting size, as reported by "parted /dev/drbd0" or somesuch, should be large enough to contain the image you've taken from the remote node's backing storage. If it's not, you're in trouble. It might be feasible to shrink the DRBD on your remote node until its data+metadata fit into the lower DRBDs. If you have spare disk space, it may be easier to enlarge the lower DRBDs, however. I probably haven't stressed this enough: dd-ing the image of the remote part of a stacked resource into the lower DRBD's backing storage isn't going to do you any good. If A and B are your local nodes with stacked resources and C is remote, you're setting yourself up to make an unstacked DRBD of A and C. Seeing as you want to perform truck-based initialization using the remote part of a stacked resource, you need to truck-initialize this stacked resource. Once that is finished, you can truck-based initialize node B to your heart's content, but that's a different story. HTH Felix On 08/06/2011 01:06 AM, Jerry Gally wrote: > >> I think you should just initialize and sync the lower DRBD device >> normally. Then perform truck-based replication using a dd *into th >> primary lower device*. > > Felix, > > According to the DRBD User's Guide truck replication process, > http://www.drbd.org/users-guide-legacy/s-using-truck-based-replication.html, > the replicated bit image must be copied onto the backing store of the > node being recovered, before bringing up the resource being recovered > (very important point, I suspect: I derived the bit image from the > remote backup node): > > 1. On the local node, issue the following command: > > drbdadm -- --clear-bitmap new-current-uuid resource > > 2. Create a consistent, verbatim copy of the resource's data and its > metadata. > > (I did 'dd if=/dev/VG00/mysql of=/pkg/nvs/cores/truck.img bs=256k') > > 3. On the local node, issue: > > drbdadm new-current-uuid resource > > 4. Physically transport the copies to the remote peer location. > > 5. Add the copies to the remote node. > > (I did 'dd if=/pkg/nvs/cores/truck.img of=/dev/VG00/mysql bs=256k') > > 6. Bring up the resource on the remote node: > > drbdadm up resource > > Sure enough, that DOES recover the lower resource: > > [root at sweng65 ~]# cat /proc/drbd > version: 8.3.7 (api:88/proto:86-91) > srcversion: EE47D8BF18AC166BE219757 > 0: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/DUnknown C r---- > ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0 > > But, it does not recover the upper resource metadata: > > [root at sweng65 ~]# drbdadm primary r0 > [root at sweng65 ~]# drbdadm --stacked up r0-U > 1: Failure: (119) No valid meta-data signature found. > > ==> Use 'drbdadm create-md res' to initialize meta-data area. <== > > Command 'drb[root at sweng65 ~]# drbdadm --stacked create-md r0-U > md_offset 1073598464 > al_offset 1073565696 > bm_offset 1073532928 > > Found ext3 filesystem > 1048440 kB data area apparently used > 1048372 kB left usable by current configuration > > Device size would be truncated, which > would corrupt data and result in > 'access beyond end of device' errors. > You need to either > * use external meta data (recommended) > * shrink that filesystem first > * zero out the device (destroy the filesystem) > Operation refused. > > Command 'drbdmeta 1 v08 /dev/drbd0 internal create-md' terminated with > exit code 40 > drbdadm create-md r0-U: exited with code 40 > dsetup 1 disk /dev/drbd0 /dev/drbd0 internal --set-defaults > --create-device --on-io-error=call-local-io-error' terminated with exit > code 10 > > And, I cannot recreate the upper resource metada without shrinking the > ext3 file system residing on the lower device: > > [root at sweng65 ~]# drbdadm --stacked create-md r0-U > md_offset 1073598464 > al_offset 1073565696 > bm_offset 1073532928 > > Found ext3 filesystem > 1048440 kB data area apparently used > 1048372 kB left usable by current configuration > > Device size would be truncated, which > would corrupt data and result in > 'access beyond end of device' errors. > You need to either > * use external meta data (recommended) > * shrink that filesystem first > * zero out the device (destroy the filesystem) > Operation refused. > > Command 'drbdmeta 1 v08 /dev/drbd0 internal create-md' terminated with > exit code 40 > drbdadm create-md r0-U: exited with code 40 >