Can I split a mirrored LV and then import the split LV on another server?

[Timothy Czarnik]

Hey all! Here is what I have:

Two HP-UX servers running 11i. Both attached to the SAN an able to see the same disk. Both have MIRROR-UX installed.

I have a filesystem on server A that is mirrored and the entire mirror exists on a single SAN disk. I'd like to split the mirror and present server B with that same disk and be able to somehow import the LV or create a VG with the disk such that the data on the disk is useable. Basically, I want to split a mirror on one server and use the mirror as an actual LV on another server.

How do I tell LVM on server A that the LV no longer exists there without doing an actual lvremove command? This is going on the assumption that using an lvremove to remove the LV on server A and then vgreducing the disk from server A would actually remove the data from the disk.

I'd really appreciate any thoughts on this! I know that I could just create a new LV and copy the data but we're looking to minimize downtime when moving a database.

Thanks in advance!

Tim

[Robert Salter]

Is this a clustered configuration? If not and two servers can see the same set of disks, your potential for excitement just went up.

[Timothy Czarnik]

This is not a clustered configuration.

[Jaime Bolanos Rojas.]

Timothy!

The main question is, how are you going to tell server B that it got a new disk, without a doing a pvcreate, on an vgcreate or lvcreate.
Those are the only ways that I know to present a new disk to an existing server. Unless it's the vg00.
To answer you other question I believe that the lvsplit command does the trick, thinking that you can actually make the server see that new drive.

Regards,

Jaime.

[Sandman!]

Yes you can do this but carefully. After splitting off the mirror lvol, create a new VG on server A. Use the vgchgid command to change the VGIDs recorded on the PV. Thereafter vgimport the PV on which the newly split lvol resides. After the new VG has been created, you can vgexport it from system A and vgimport it to system B.

The vgchgid command was designed for use with the BCVs created from EMC Symmetrix arrays. The BCVs are the same as the lvols created with the lvsplit command.

~hope it helps

[Robert Salter]

What you're looking to do could possibly be accomplished, but not recommended.

Are you looking to keep the database active on A as well as B? Or will A not be used when things are moved over to B?

[George Liu_4]

Yes. You can. This is a way I normally do to prepare a cold backup.

[Rita C Workman]

Tim,

What your attempting to do is (without the extra fancy software) to create what we call a BCV (business continance volume).
Yes you can do it...

But it is a bit tricky this way...since you know how to split the mirror-I'll omit that syntax.
You have to create your mapfile from node A and copy that file over to node B.
Now on node B you do:
mkdir
mknod
NOW the FUN...
vgimport with that mapfile BUT.....................................
the trick is you only want the mirrored disk. So to ensure you don't get disk-brain stroke happening, you have to create a file that has /dev/dsk/c-t-d (in one continual line) of the disk addresses of ONLY those mirrored disk.
So your vgimport might look something like this:
vgimport -v -m /etc/lvmconf/vgmapfile -f /path/ /dev/vgname

Create your mount points; run fsck on them NEXT and then see if you can mount them.

You could script all of this, to take them down, allow them to remirror, and then split and remount. We use EMC Timefinder software to lend us a hand. But if your flying solo...then you'll have a great opportunity to prove your 'metal'.

Hope this helps,
Rgrds,
Rita

[Timothy Czarnik]

Hey all,

Thanks for the responses! I'm going to attempt the process that Rita describes. I'm sure it will work because, let's face it, it's Rita :)

I will follow up with the results. Thanks again!

Tim

[Rita C Workman]

Well then let me also remind you to backup first !

Rgrds,
Rita

[marvik]

Hi Tim,

Can u pls update if you are able to get this task done and how u did that?I think Rita's idea was good ,You faced any issues with that

Cheers!
Marvik

[Timothy Czarnik]

Hey all,

I've had no luck with this unfortunately. This is the message that I am getting:

/root # vgimport -v -m /root/mapfile -f /root/vgdisk /dev/vg02

Beginning the import process on Volume Group "/dev/vg02".

vgimport: Warning: Volume Group belongs to different CPU ID.

Can not determine if Volume Group is in use on another system. Continuing.

Logical Volume is not defined on any physical volume.

"/dev/vg02/lvol1_copy" is missing Physical Volumes.

Volume group "/dev/vg02" has been successfully created.

Warning: A backup of this volume group may not exist on this machine.

Please remember to take a backup using the vgcfgbackup command after activating the volume group.


It says the vg is created but it's not.

Any ideas?

Tim

[Timothy Czarnik]

I believe I need to do a combination of Rita's and Sandman's responses. It looks like the vgchgid is the command I'll need to get around the "Volume Group belongs to different CPU ID" message. Heading back to play around a bit...

Tim

[Sandman!]

Take a look the the tkb doc below:

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000066374323

~hope it helps

[Timothy Czarnik]

Well I was able to do this, however the imported volume group still created the old logical volumes even though I didn't import their disks in the disk file or include them in the mapfile.

Bottom line is I believe this can be done but probably shouldn't be done with disks that contain data of any importance. It is extremely easy to get your LVM out of whack.

In the end, I will still mirror the data that needs to move onto disks at the remote location and on the day of the move I'll remove the mirror copy from the local disks so the data remains on the disks at the remote location.

Thanks for the help everyone!

Tim