Data Migration

[Shahnaz bin Abdul Mutal]

Hi Folks;

I got a question for you guys. I just purchased a new EMC storage. I would like to migrate the data using mirrordisk/UX where I mirror from my current disk to the EMC. But here is a slight problem. My data is about 2TB. After the mirroring is done, I would like to break the mirror and take volume on EMC, assign it to another host so that I can do some testing on the data. Here are the steps that I have put .. Would like all those guru's out there to verify. I won't state the mirror steps, just the steps in breaking the mirror and also mounting on the other host.

1. lvreduce -m 0 /dev/vg01/lvol1 /dev/dsk/c24t0d0

2. Perform a vgimport -m vg01.map vg01

On the testing host.

1. mkdir /dev/vg01
2. mknod /dev/vg01/group c 64 0x010000
3. vgimport -m vg01.map vg01 /dev/dsk/c24t0d0
4. vgchange -a y vg01

Is the steps above possible ? Appreciate your kind help.

[Bruno Vidal]

Sorry, this procedure won't work at all.
When doing lvreduce -m 0 your are removing LVM structure from this device, if you want do this by using MIRROR:
1. save /etc/lvmconf somewhere in case of probleme
2. lvreduce -m 0 /dev/vgXX/lvolXX disk_old_array

3. vgreduce /dev/vgXX disk_old_array

4. importe on the other host

In case of failure you can still restore LVM structure on the old array by using vgcfgrestore (look at man pages to use alternate config file).

Cheers.

[Bruno Vidal]

Btw, I think a better solution to do your data migration would be:
1. create an entire new vg with you new EMC.

2. create new lvol and use dd if=/dev/vgXX/rlvol of=/dev/newvgXX/rlvol bs=512
in order to do the copy

3. export/import on the hosts

The advantage:
-can do multiple lvol copy at the same in order to reduce the downtime.
-can create en antire new LVM structure in order to use distributed, stripping, whatever you want, new PE size, etc... By using Mirror, you should use the same PE size, the same LVM structures, the same limitations.

Cheers.

[Shahnaz bin Abdul Mutal]

Hi Bruno;

What I am doing is not removing the disk from the current vg config. I believe that when you do a vgreduce then only the vg information is destroyed. I will still leave the EMC disks presented to the production system while doing testing on the testing system. I will not do a vgreduce. If you don't do that, then it will work right.....

[Shahnaz bin Abdul Mutal]

Hi Bruno;

The reason that I am using mirroring is becuase I can do it online with the database up. I only need a short offline time to perform the lvreduce. DD is not possible due to the long downtime that is incurred.

[Bruno Vidal]

Sorry, but when doing an lvreduce, you are truly removing LVM information on disk, it is true that DAT are still on the disk, but LVM structures have been destroyed. Yes, you can do it online, but performance will be really bad. And as I said, you must keep the same LVM configuration, it means that you cannot change anything, and you should assign disk of the same size (if your lun were too small, your new lun will be still too small also).
Now, as it has been discussed last friday, you can do it like this, you will have to create new lvol like the orignal structures, and it is not so easy, and I will certainly not advise you to do this without a strong knwoledge of LVM. If you still want do this the procedure should looks like this:
1. mirror to you new disk
2. stop database,lvreduce/vgreduce,restart database.
3. on test host: vgcreate (same PE size)
4. lvcreate (same exact size at least)
but the hard part is here, you should recreate lvol with the same PE assignment than the original lvol
5. fsck (because you want did this online)

[Michael Steele_2]

Migrating data between disk arrays through LVM mirroring can only be done when both disk sizes, between old and new, are identical. Otherwise, you will be overlaying a typically smaller disk map onto a larger disk and never get full disk memory utilization.

So its best to reduce out one controller, reattach it to the new disk array and make new vgs. Its the only way with different disk sizes.

When reducing out a controller, aka one of the pvlinks, verify primary or alternate for every vg and 'pvchange -s y/n /dev/dsk/c#t#d#' where needed. Map this out ahead of time.

Once you have the new vgs created, make new lvs and file systems, a temp. mount point and copy over the data between file systems, and test with cksum between old and new. When ready remove the old vgs, move the controller (* HBA *) to the new disk array and vgextend in for alternate pv link.

In short, while mirroring will work, it often time creates another problem so best to create new vgs.