使用LVM（逻辑卷管理）对MySQL进行备份
时间：2007-02-03 来源：gladness
LVM（逻辑卷管理）为MySQL备份提供非常有效的一个手段，特别当使用的表都是InnoDB引擎时，可以进行真正意义的热备，并且备份与恢复速度要比mysqldump快。
使用LVM的快照技术，可以迅速地为某逻辑卷建立快照。而MySQL的数据文件所在目录，可以挂载一个逻辑卷，以便用快照进行备份。
比如在我实验的机器(RHEL4.0)上：
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
28770436 6957988 20350996 26% /
/dev/sda1 101086 12579 83288 14% /boot
none 517312 0 517312 0% /dev/shm
/dev/mapper/VolGroup00-data
6194624 496464 5446504 9% /var/lib/mysql
/var/lib/mysql下挂载的是名字为data的逻辑卷，它属于卷组VolGroup00
列出所有物理卷：
pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a- 29.88G 64.00M
/dev/sdb1 VolGroup00 lvm2 a- 3.91G 0
/dev/sdb2 VolGroup00 lvm2 a- 2.97G 2.97G
/dev/sdb3 VolGroup00 lvm2 a- 3.09G 1.00G
列出所有卷组：
vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup00 4 3 0 wz--n 39.84G 4.03G
列出所有逻辑卷：
lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
LogVol00 VolGroup00 -wi-ao 27.88G
LogVol01 VolGroup00 -wi-ao 1.94G
data VolGroup00 -wi-ao 6.00G
物理卷可以是一块硬盘或者硬盘上的一个分区；
卷组用来建立逻辑卷与物理卷的关系，一个卷组可以有多个逻辑卷，多个物理卷；
文件系统建立在逻辑卷之上，逻辑卷可以使用与其在同一卷组中的物理卷。
建立快照：
lvcreate -L 1G -s -n snap /dev/VolGroup00/data
Logical volume "snap" created
即创建一个新的逻辑卷，大小为1G，名字为snap，它是卷组VolGroup00下的逻辑卷data的快照。建立快照的时候并不会阻塞MySQL对数据文件的任何操作，读和写都不会阻塞。并且快照的建立并不是复制所有逻辑卷中的文件，它只是要把在创建快照的时刻之后的逻辑卷中的变化记录下来，因此快照很快就创建好了。
挂载新创建的卷：
mount /dev/mapper/VolGroup00-snap /mnt/snap/
ls /mnt/snap/
ibdata1 mysql mysql.sock
ib_logfile0 mysql_bin.000001 sbtest
ib_logfile1 mysql_bin.000002 test
lost+found mysql_bin.index
好了，此时可以把/mnt/snap目录进行备份，比如打包后复制到备份介质中去。由于使用的是全都是InnoDB表，因此备份过程中也不需要获得MySQL的全局读锁。备份快照中的文件时，尽管此时MySQL仍然可能有写操作，在修改数据文件，但在快照中”看“到的各个文件都是创建快照那一时刻的状态。因此可以放心地复制。再加上InnoDB可以依据日志进行恢复，因此不把此时缓存中的数据刷新到文件中也是没有问题的。即利用此备份进行恢复或者建立一个slave都是可以的。
备份完成之后，解除mount
umount /mnt/snap/
删除快照
lvremove /dev/VolGroup00/snap
Do you really want to remove active logical volume "snap"? [y/n]: y
Logical volume "snap" successfully removed
还有一件事不要忘了，备份出来的binary log，要看一下最新的文件和位置，比如：
mysqlbinlog mysql_bin.000002|tail
# at 186376687
#070203 0:44:01 server id 1 end_log_pos 665 Query thread_id=428 exec_time=0 error_code=0
SET TIMESTAMP=1170434641;
INSERT INTO sbtest values(496413,0,' ','aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy');
# at 186376844
#070203 0:44:01 server id 1 end_log_pos 186376871 Xid = 5139754
COMMIT;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
最后一个end_log_pos后面的值186376871是恢复或者是制做slave时需要指定的位置，当然日志文件的名字也要记住。如果binary log比较大，上面的那个操作可能会花比较长的时间。
这样的备份，意义在于：
1.备份恢复要比mysqldump快
2.是完全意义的热备
3.用来制做slave也非常方便
还有需要注意的是，依然是要在系统不忙的时候进行，并且快照要有足够的空间。如果备份时有比较频繁的数据库写入操作，快照需要的空间就会比较大。有人提到，一般的经验，快照为所有备份文件的30%就足够了。
做了几次试验，在数据库压力很大的情况下，都备份成功了，并且也成功制做了slave。
但也有一次例外，lvremove一直没有反应，并且导致系统负载一直很高，连mysqld都crash了，其日志中说获取信号灯超时。到网上搜了搜，似乎是lvm的bug，具体的没深入去看。
使用LVM的快照技术，可以迅速地为某逻辑卷建立快照。而MySQL的数据文件所在目录，可以挂载一个逻辑卷，以便用快照进行备份。
比如在我实验的机器(RHEL4.0)上：
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
28770436 6957988 20350996 26% /
/dev/sda1 101086 12579 83288 14% /boot
none 517312 0 517312 0% /dev/shm
/dev/mapper/VolGroup00-data
6194624 496464 5446504 9% /var/lib/mysql
/var/lib/mysql下挂载的是名字为data的逻辑卷，它属于卷组VolGroup00
列出所有物理卷：
pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a- 29.88G 64.00M
/dev/sdb1 VolGroup00 lvm2 a- 3.91G 0
/dev/sdb2 VolGroup00 lvm2 a- 2.97G 2.97G
/dev/sdb3 VolGroup00 lvm2 a- 3.09G 1.00G
列出所有卷组：
vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup00 4 3 0 wz--n 39.84G 4.03G
列出所有逻辑卷：
lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
LogVol00 VolGroup00 -wi-ao 27.88G
LogVol01 VolGroup00 -wi-ao 1.94G
data VolGroup00 -wi-ao 6.00G
物理卷可以是一块硬盘或者硬盘上的一个分区；
卷组用来建立逻辑卷与物理卷的关系，一个卷组可以有多个逻辑卷，多个物理卷；
文件系统建立在逻辑卷之上，逻辑卷可以使用与其在同一卷组中的物理卷。
建立快照：
lvcreate -L 1G -s -n snap /dev/VolGroup00/data
Logical volume "snap" created
即创建一个新的逻辑卷，大小为1G，名字为snap，它是卷组VolGroup00下的逻辑卷data的快照。建立快照的时候并不会阻塞MySQL对数据文件的任何操作，读和写都不会阻塞。并且快照的建立并不是复制所有逻辑卷中的文件，它只是要把在创建快照的时刻之后的逻辑卷中的变化记录下来，因此快照很快就创建好了。
挂载新创建的卷：
mount /dev/mapper/VolGroup00-snap /mnt/snap/
ls /mnt/snap/
ibdata1 mysql mysql.sock
ib_logfile0 mysql_bin.000001 sbtest
ib_logfile1 mysql_bin.000002 test
lost+found mysql_bin.index
好了，此时可以把/mnt/snap目录进行备份，比如打包后复制到备份介质中去。由于使用的是全都是InnoDB表，因此备份过程中也不需要获得MySQL的全局读锁。备份快照中的文件时，尽管此时MySQL仍然可能有写操作，在修改数据文件，但在快照中”看“到的各个文件都是创建快照那一时刻的状态。因此可以放心地复制。再加上InnoDB可以依据日志进行恢复，因此不把此时缓存中的数据刷新到文件中也是没有问题的。即利用此备份进行恢复或者建立一个slave都是可以的。
备份完成之后，解除mount
umount /mnt/snap/
删除快照
lvremove /dev/VolGroup00/snap
Do you really want to remove active logical volume "snap"? [y/n]: y
Logical volume "snap" successfully removed
还有一件事不要忘了，备份出来的binary log，要看一下最新的文件和位置，比如：
mysqlbinlog mysql_bin.000002|tail
# at 186376687
#070203 0:44:01 server id 1 end_log_pos 665 Query thread_id=428 exec_time=0 error_code=0
SET TIMESTAMP=1170434641;
INSERT INTO sbtest values(496413,0,' ','aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy');
# at 186376844
#070203 0:44:01 server id 1 end_log_pos 186376871 Xid = 5139754
COMMIT;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
最后一个end_log_pos后面的值186376871是恢复或者是制做slave时需要指定的位置，当然日志文件的名字也要记住。如果binary log比较大，上面的那个操作可能会花比较长的时间。
这样的备份，意义在于：
1.备份恢复要比mysqldump快
2.是完全意义的热备
3.用来制做slave也非常方便
还有需要注意的是，依然是要在系统不忙的时候进行，并且快照要有足够的空间。如果备份时有比较频繁的数据库写入操作，快照需要的空间就会比较大。有人提到，一般的经验，快照为所有备份文件的30%就足够了。
做了几次试验，在数据库压力很大的情况下，都备份成功了，并且也成功制做了slave。
但也有一次例外，lvremove一直没有反应，并且导致系统负载一直很高，连mysqld都crash了，其日志中说获取信号灯超时。到网上搜了搜，似乎是lvm的bug，具体的没深入去看。
相关阅读 更多 +
