[ale] lvconvert adding mirror speed considerations

[Jim Kinney]

Did you take a snapshot prior to the mirror? That will quell the disk
changes for a huge chunk. May be faster/easier to export/dd/rsync the
snapshot to the new storage, resnapshot, repeat migrate for older
snapshot, repeat until snapshot is small enough for downtime, shut off
DB, finalize mirror, break mirror, restart DB on new space. Then you
only have to flatten all the snapshots. (Woo! Fun!)
On Thu, 2016-12-01 at 22:04 +0000, Lightner, Jeffrey wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-- 
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20161201/00ba441f/attachment.html>