Mirroring

[Pete Randall]

My 140GB production database resides on two SC10 enclosures of a FC60 disk array configured as RAID 0/1. What I would like to do is use software mirroring (MirrorDisk/UX) to replicate that database onto the (currently empty) third SC10 of the same array which is configured as RAID 5. I can then split off the mirrors and use the replicated copy as my development database (I hope).

The questions that occur to me are:
1) Am I completely out of my mind?
2) All these lvols have to be in the same VG, right?
3) The mirror copy starts when the mirror is created via lvextend, right?
4) How long is it going to take to copy 140GB of data to the new mirrors?
5) How do I activate the VG in shared mode between the production and development server?
6) Is there a good reference on MirrorDisk/UX out there? All I see is bits and pieces.

Thanks,
Pete

[Sandip Ghosh]

You can do the above as follows:

1. Include new LUNs on the existing VG.
2. Do lvextend -m 1 to create the mirror.
3. then break the mirror.
4. Connect the new SC10 to the dev server.
5. Create /dev/vgXX directory and the group file under it.
6. Do vgimport with the LUNs of the new SC10.

Sandip

[Luc Bussieres_1]

Pete,

I'm not an expert with performance so I will let question 1 without an answer since the only thing that this could bring you would be a performance improvement.

2) yes all the lvols needs to be in the same VG to use mirroring.
3) exactly
4) 140Gig will take a looooonnnng time I'm not sure of the exact time but I would say multiple hours.
5) What do you really wants to achieve exactly, there is a shared mode available in the VG configuration but I have seen it used only with OPS (oracle parallel server) there could be some other solution like NFS or ServiceGuard depending what you want to do
6) I have not seen any...

I hope this help
Luc

[James R. Ferguson · Accepted solution]

Hi Pete:

In order:

1. No, you can use MirrorDisk/UX to replicate.

2. Yes, mirroring is done at the *logical volume* level, so your mirrors (logical volumes) will have to be part of the *same* volume group as that from which you start.

3. Yes, the mirror copy is established with 'lvextend -m 1 ...' (see the man pages of 'lvextend' for details).

4. Mirroring is fast, but "how long" really depends on the I/O characteristics and load on the channels you are using.

5. At most, you will only be able to share a volume group as readonly. Only *one* copy of LVM should ever have write-access.

6. A reasonably good reference for MirrorDisk/UX is the "Managing Systems and Workgroups: A Guide for HP-UX System Administrators". See the section of high-availability strategies.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Pete:

Sorry, for the "Managing Systems and Workgroups: A Guide for HP-UX System Administrators" the link is:

http://docs.hp.com/hpux/onlinedocs/B2355-90742/B2355-90742.html

Regards!

...JRF...

[Luc Bussieres_1]

I think I read your message to fast the first time.
1) no the way you want to do it make sense and the steps sandip as told you to do it make sense.

[Martin Johnson]

In response to question 5: It depends on what you mean by "shared mode". You can use ServiceGuard to share the data, but it can only be active on one node at a time.

If you want the data to be shared, that would depend on the database software you are using. Sybase and Oracle support replication servers where when one copy of the database is updated, the other copy is also updated.

Remember to have all files closed before you break the mirror. Otherwise you can have corrupted data.

HTH
Marty

[Helen French]

Just my thoughts:

1) About the mind, honestly I don't know =)) But it look like you are on the track.

2) I would not agree completely with that. It depends on the current configuration. If in case you have two lvols now (in vg01 and vg02), then you have to add one LUN in vg01 and the next to vg02 and then mirror each one. The rule is - You could do mirroring (software) only in the same VG.

3) Yes.

4) It depends on your system's resource and device speeds. I think it will be faster if you run simultaneous mirrorings on different lvols.

5) I think, You need to have cluster configuration in order to do this. There is an option with vgchange (-a s), but there are limitations for this. Read man pages

6) This will be a good reference, read chapter -7 :

http://www.docs.hp.com/hpux/onlinedocs/B2355-90672/B2355-90672.html

[Pete Randall]

Aarrrgh!

The whole point of this exercise was to share the replicated data with the development server. The part I missed in the original concept was that the lvols would have to be in the same volume group and the volume group can't be activated in shared mode without high availablity software (that's pronounced MCService Guard, I believe).

One last (extremely desperate) question:
can anyone think of some deviously clever way to fool the system and move lvols from one VG to another?

Pete

[James R. Ferguson]

Hi Pete:

Moving logical volumes (that is, the filesystem's contained within them) is easy:

# cd /myolddir || exit 1
# find . -depth ???print | cpio -pudlmv /mynewdir

When done, you can edit '/etc/fstab' to rename '/mynewdir' to the name ('/myolddir') it was before you started (or leave it alone if you want replicated data). If you were renaming it to its old name (i.e. moving your data from one logical volume to another, perhaps on a different volume group) then you would simply remove the old mountpoints from '/etc/fstab' and renmae the new ones.

Regards!

...JRF...

[Pete Randall]

Ahh yes, James, but these are not filesystems, they are the raw logical volumes of an Informix database. That's why I was looking for the proverbial "lvexport" command.

Pete

[James R. Ferguson]

Hi (again) Pete:

...in that case, I would look use 'dd' to copy the data.

Regards!

...JRF...

[Luc Bussieres_1]

Pete,

The only way I could imagine would be to create identical lvols in a different VG and then to use the dd command to copy the raw data over.

What you would really need is something like the bcvsplit (business copy) that is supported by high end disk array (EMC, XP)

You could try to simulate it also by using dd to copy the contents of your original LUNS to the new ones, and then to run a vgchgid on the new LUNS.

Luc

[Pete Randall]

Actually, James, the more I think about it, that's really exactly what I want to accomplish. If I make the third SC10 it's own separate VG and set up a script to dd from the production lvols to the development lvols, deactivate the volume group on the production machine, then activate it on the development machine, I've got almost exactly what I was looking for. Can you see any other gotchas? I seem to have a bad case of tunnel vision. Either that or I can't see the forest for the trees. Thanks for your help.

Pete

[James R. Ferguson]

Hi (again) Pete:

I think that will work. For efficiency, of course, use a large block size with 'dd' and make sure that nothing is using the sending data! I admit, that I have never played with raw stuff -- only LVM.

Regards!

...JRF...

[Pete Randall]

And on that note - my thanks to all of you for your very valuable assistance.

Pete

[George Petrides_1]

Pete, when you start lvextend -m 1 .... then it takes about 10-20 minutes per GB to mirror so I expect to take about 24-48 hours to complete. Then, before splitting the mirrors, make sure your database is down else the copied/splitted data will probably be corrupted. If you are planning to use the offline mirrors on another server, then that is quite complicated. If you try what another fella suggested with just importing and activating the groups on the development server, then you will loose your production data since ONLY ONE server at a time can access a volume group. Hope this helps.