LVM snapshots are very scary for InnoDB under certain circumstances. Why?
If you have innodb_file_per_table disabled, ibdata1 will have everything and its grandmother in it. What lives in ibdata1? Four things:
- Data Pages
- Index Pages
- Metadata (such as List of TableSpave IDs)
- MVCC Data
If you are trying to perform LVM snapshots in a heavy-write DB environment with innodb_file_per_table off, you may be shooting yourself in the foot. An LVM snapshot needs the ibdata1 file to be well coaleseced beforehand.
I recently performed an experiment as follows:
A client at my employer's web hosting company has the following issues with their MySQL Setup:
- innodb_file_per_table off
- 1.4TB ibdata1
- only 29GB free within ibdata1
- ext3 filesystem (Single File Size Limit of 2GB, yuck)
I wanted to setup a MySQL Slave by rsycning the /var/lib/mysql folder to another DB Server. When the rsync was done on ibdata1 without downtime, it took 42 hours. The second rsync against ibdata1 took 84 hours, only found 220GB of changes, and was barely 15% done. I aborted that mission.
An LVM snapshot may perform much better that an rsync. Notwithstanding, any LVM snapshot involving a very large ibdata1 will be subject to the same issues.
If you go with LVM snapshot, please use these options:
- OPTION 01) Use innodb_file_per_table. LVM snapshots will love you for it because it will be dealing with smaller files. You can also permanently shrink ibdata1.
- OPTION 02) Use MySQL Replication and do LVM snapshots on the Slave
With a MySQL Replication Slave, you can
STOP SLAVE;
(if you have --skip-slave-start in my.cnf)
service mysql stop
- perform the LVM snpshot
service mysql start
START SLAVE;
(if you have --skip-slave-start in my.cnf)
That way, these LVM snapshot issues will never see the light of day on a Production Master.
Give it a Try, and have fun with this !!!