Re: LVM-snapshot + mysqldump -- is this a reasonable backup strategy?

[Gleb Paharenko]

Hello.

A few months ago you've been writing about issues with InnoDB
when using a similar recipe. Please, share your experience of
how you've solved that problems.


"James G. Sack (jim)" <jsack@stripped> wrote:
> This recipe is intended to minimize the impact on ongoing database
> operations by inhibiting writes only during a relatively speedy
> operation (creating a snapshot). The long dump operation can then be
> performed on the (stable) snapshot, without interfering with ongoing use
> of the live database.
> 
> 1. effectively quiesce and stabilize the database via "flush tables
> with read lock"
> 
> 2. while writes are locked-out, make an LVM snapshot of the filesystem
> containing the db
> 
> 3. after snapshot creation finishes, release the write-lockout via
> "unlock tables" 
> 
> 4. mount the snapshot
> 
> 5. load a second database server daemon accessing the db within the
> snapshot (with a suitable alternate my.cnf file)
> 
> 6. perform mysqldump operation on the snapshot-db
> 
> 7. cleanup (unload second db server, unmount and delete snapshot)
> 
> So what monsters lurk within this backup strategy?
> ..jim
> 
> 


-- 
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Gleb Paharenko
 / /|_/ / // /\ \/ /_/ / /__   Gleb.Paharenko@stripped
/_/  /_/\_, /___/\___\_\___/   MySQL AB / Ensita.NET
       <___/   www.mysql.com