A more practical solution for a larger MySQL instance is to perform a filesystem snapshot.
This is not actually a MySQL specific strategy, but rather a disk based operating system command using Logical Volume Manager (LVM) for direct attached drives, or applicable snapshot technology for Storage Area Network (SAN) or Network Attached Storage (NAS) providers. This may also be a feature of certain file systems, e.g., the Btrfs file system on Linux and ZFS on Solaris.
Your disk must be correctly configured with LVM prior to using any of these commands. The EffectiveMySQL website provides a detailed article on installing and configuring LVM at http://effectiveMySQL.com/article/configuring-a-new-hard-drive-for-lvm/ and on installing MySQL to utilize this LVM volume at http://effectiveMySQL.com/article/using-mysql-with-lvm.
Assuming you have a MySQL instance running on an LVM volume you can use the following command to take a filesystem snapshot:
This command uses the logical volume group (dev/db/p0) and a very small undo size for this example (-L1G). These would be modified accordingly for your environment.
Calculating the necessary undo size can be difficult. If the space is not large enough, the snapshot command will report an appropriate error.
NOTE A snapshot volume does not need to be the same size as the underlying volume that contains your MySQL data. A snapshot only has to be large enough to store all data that is going to change over the time the snapshot exists.
CAUTION Always ensure you have sufficient diskspace to perform a snapshot. The
pvdisplay and lvdisplay commands show total available space and the percentage of space allocated to snapshots.
CAUTION Having an active LVM snapshot comes with a performance penalty for all disk activity. While ideal for recovery purposes to have the current snapshot online, for general database performance it is best to discard the snapshot as soon as it is no longer in use. Having multiple snapshots will further degrade I/O performance.
The verification process of taking a filesystem snapshot would include:
LVM snapshots operate under the filesystem; they are thus application and filesystem agnostic. Whatever application uses these files—in this case, MySQL—needs to ensure that the files on disk are in a consistent state when the snapshot is taken. This backup approach works; however, it creates an inconsistent snapshot of MySQL. Depending on the storage engines used, the recovery process may perform an automatic recovery for this inconsistent view, or it may produce errors, for example, with MyISAM tables, which can increase the total system recovery time. Historically, automatic recovery time with InnoDB could also take a long time. This has been greatly improved with newer versions of MySQL 5.1 and 5.5.
The correct approach when using a filesystem snapshot is to place the MySQL instance into a consistent state before any command. This is achieved with the FLUSH TABLES WITH READ LOCK command. As described in the earlier section on locking, this command, when used incorrectly, does not ensure a consistent view.
The recommended steps for using a filesystem snapshot are:
• Generate a consistent MySQL view with FLUSH TABLES WITH READ LOCK. It can be difficult to predict how long this will take.
• Obtain the MySQL binary log position with SHOW MASTER STATUS and/or SHOW SLAVE STATUS.
• Run the snapshot command in a different thread. It is important you do not exit from the MySQL session for the previous commands.
• Optionally run a FLUSH BINARY LOGS.
• Release locks with UNLOCK TABLES.
• Verify the filesystem snapshot.
• Make an appropriate copy of the snapshot backup on a different server or site.
• Discard the snapshot (for optimal I/O performance).
NOTE The most common backup needed for a disaster recovery is the most recent backup. The underlying LVM logical volume for the filesystem snapshot is actually an I/O performance overhead to maintain. The backup of the snapshot and movement to an external system is a common approach. The restoration of these compressed backup files from an external system can be the most significant time component of the recovery strategy. Chapters 3 and 5 discuss these impacts in more detail.
For more information about the theory of LVM see http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux).
Using mylvmbackup
The mylvmbackup utility now maintained by longtime MySQL community advocate Lenz Grimmer is a convenience script that wraps all of this work into a single command. You can find this utility at http://www.lenzg.net/mylvmbackup/. For example, the use of
mylvmbackup when correctly installed and configured is:
This command supports many additional features including backing up to a remote server using rsync. The Effective MySQL article at http://effective-MySQL.com/article/creating-mysql-backups-using-lvm/ provides additional information on how to correctly install and configure mylvmbackup and also lists several valuable external references.
TIP A snapshot is a great way to perform software updates. There is no need to back up and remove the snapshot for this operation. If the update fails you can roll back to the snapshot just taken.
Designing Appropriate LVM Volumes
There are several considerations for optimizing the use of LVM and MySQL. Ensure you have a dedicated logical volume for your MySQL instance. This should include the data and InnoDB transactional logs. This is critical for a successful recovery. A snapshot is an atomic operation for all files at the same time per logical volume. Having data and InnoDB transaction logs on separate volumes would not ensure a consistent snapshot, as this would be performed separately per volume. While the MySQL binary logs are good to keep with your MySQL backup, for a highly loaded system, it may be beneficial to separate this from your MySQL data volume. MySQL log files, or other monitoring or instrumentation, can also cause overhead; the goal should be to minimize your disk footprint to ensure the most optimal recovery time.
Limiting other operations that affect your data during the execution of a filesystem snapshot can also improve the performance. For example, disabling or limiting batch processes and reporting can reduce additional system load.
Other Considerations
Using filesystem snapshots can be a disk I/O intensive operation. If your system is already
heavily loaded, the addition of an active snapshot is an overhead that could add up to 20 percent extra load. In addition, the compressing and/or copying of the snapshot, while necessary for a backup strategy, may add more stress to the system.
The ZFS filesystem, available with Solaris, FreeBSD, and other free Solaris derivative operating systems, provides a native snapshot command that works very efficiently with the designed copy-on-write principle. The Btrfs filesystem for Linux is another snapshot efficient option. Other filesystem types such as xfs can provide different performance benefits for disk I/O and management with snapshots.