[ale] lvconvert adding mirror speed considerations

[Lightner, Jeffrey]

We're in the process of migrating from one disk array to another.

The method we're using is to zone in the new array to the same fabric(s) in which we have the existing servers and old array then allocate storage from the new array to the servers.
We then use vgextend to add the new storage device PVs to the existing VG and also add a small device to be used for LVM mirror logging.   After that we use lvconvert to turn on mirroring for an LV specifying the new PVs (including the log device).
Once the mirror is complete we do lvconvert to turn off mirroring specifying the old PVs to remove (and the log device).

This worked fine for a couple of smaller LVs we did yesterday.   We then started one to a 6.3 TB LV.   That has now been running for over 24 hours and appears it will complete around 10 PM tonight.

I suspect this is taking a long time because it has an underlying database on the LV and we are doing this with that database online.

We intend to do a test with a separate instance where we shut down the database so it is quiesced.    I'm just wondering if anyone has done this kind of thing before and if so whether you significant improvement when running the mirror creation with everything quiesced as opposed to with everything running?

Alternatively does anyone know of any tricks that would help increase the speed?

The above is fine for test/dev but we wouldn't want this much downtime on our main Production database and aren't sure we would want to do it online anyway owing to other considerations related to backup windows.

Also I'm curious if anyone knows if there is a way with lvconvert to force it to use a specific PV device as the mlog device>   So far it appears to use the small one we created automatically.   However, since I don't see a way to specify the mlog device it isn't clear if it is just automatically picking the smallest one or not.   It doesn't appear to matter what order we give the mlog device in the lvconvert command along with the other PVs intended for the data rather than the log.




CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20161201/69023e1b/attachment.html>