JoeCen's 小猫窝

恢常简单，内核原生支持，只需要用apt安装即可：

基本的使用方法:

建立PV

为把一个磁盘或分区作为PV，首先应使用 pvcreate 对其初始化，如对IDE硬盘/dev/hdb， “使用整个磁盘，

# pvcreate /dev/sda

这会删除sda上所有的数据，并初始化为lvm的格式

建立vg（卷组）
vgcreate test_vg /dev/sda

然后可用vgdisplay 查看／验证卷组的信息：

# vgdisplay

创建lv（逻辑卷）
lvcreate -L100G –niotest test_vg

该命令就在卷组test_vg上创建名字为iotest，大小为100G的逻辑卷，并且设备入口为/dev/test_vg /iotest（test_vg 为卷组名，iotest为逻辑卷名）。

然后就可以像普通的分区一样，对iotest进行初始化和挂载：

mkfs.ext3 /dev/test_vg/iotest
mount /dev/test_vg/iotest /home/mysql

建立mysql

直接将mysql的数据目录设置为/home/mysql即可。

snapshot的原理

我们知道，LVM snapshot的原理是当一个snapshot创建的时候，仅拷贝原始卷里数据的元数据(meta-data)。
创建的时候，并不会有数据的物理拷贝，因此snapshot的创建几乎是实时的，当原始卷上有写操作执行时，
snapshot跟踪原始卷块的改变，这个时候原始卷上将要改变的数据在改变之前被拷贝到snapshot预留的空间里，
因此这个原理的实现叫做写时复制(copy-on-write)。
在写操作写入块之前，CoW讲原始数据移动到 snapshot空间里，这样就保证了所有的数据在snapshot创建时保持一致。
而对于snapshot的读操作，如果是读取数据块是没有修改过的，那么会将读操作直接重定向到原始卷上，
如果是要读取已经修改过的块，那么就读取拷贝到snapshot中的块。

这样，通常的文件I/0流程有一个改变，那就是在文件系统和设备驱动之间增加了一个cow层，变成了下面这个样子：

file I/0 —> filesystem — >CoW –> block I /O

（上述文字引自 http://blog.wgzhao.com/2008/06/20/LVM-snapshot-on.html）

创建snapshot的命令
lvcreate --size 20G --snapshot --name snap /dev/newvg/iotest

上述命令为iotest创建了一个名为snap的，大小为20G的快照。

使用lvm snapshot备份mysql数据库的过程
FLUSH TABLES
FLUSH TABLES WITH READ LOCK
Create the snapshop (lvcreate -s)
(SHOW MASTER/SLAVE STATUS)
UNLOCK TABLES
Mount snapshot, perform backup
Unmount and discard the snapshot (lvremove)

简单的说，就是先把所有表锁了，然后对逻辑卷建立一个快照（1 秒左右），必要的话show master/slave status把当前的posision记录下来，然后就可以unlock 表，恢复服务了。用脚本来进行上述操作的话，只需要2、3秒即可完成。恢复服务后，可以把snapshot挂载到某个目录下，然后对其进行备份（tar+zip之类）。

与ibbackup相比，使用LVM备份的灵活性更高，比如可以自己选择备份的工具（gzip、7zip甚至不进行压缩直接进行远程拷贝）；做了 snapshot之后也可以不开始进行备份，比如对数据库进行了不确定的操作，这时候就可以先做个snapshot，然后进行观察，如果没有问题的话直接把snapshot删除就可以了，无需要备份。

已经有开源的工具实现LVM备份的功能,那就是MyLVMBackup 项目地址是： http://lenzg.net/mylvmbackup/

安装

debian需要提前安装的包 包括

libconfig-inifiles-perl, libtimedate-perl, libdbi-perl, libdbd-mysql-perl

解压 mylvmbackup包，进入其目录，运行：

make install

即可完成安装其实安装的只是一个 perl写的脚本和配置文件；

配置

配置文件在

/etc/mylvmbackup.conf

在里面配置好mysql和LVM的基本信息，比如mysql的用户、密码、端口等，LVM的vgname、lvname等；然后是备份的信息，mount在哪里、备份目录等；

最后是gzip 参数–best修改为–fast，当然你也可以用–best，但是备份时间会增加几倍。另外也可以选择其他的压缩工具和参数，具体查看该配置文件。

测试结果

测试数据大小：26G
存储引擎：innodb
备份时间：

ibbackup      16分钟
mylvmbackup (gzip –fast) 12分钟

（ibbackup使用默认参数）

从结果上看，mylvmbackup的效果比较好。
不过我们不能用它来进行数据库备份，因为它却有其他的问题:

在我的测试环境中（Dell 1950 RAID1）LVM做了snapshot之后的写入性能非常差，甚至比没有做snapshot之前要慢5-10倍。测试数据如下：

postmark

未做snapshot前的测试:

PostMark v1.51 : 8/14/01
pm>set number 10000
pm>set size 300000
pm>set transactions 10000
pm>run
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
    157 seconds total
    67 seconds of transactions (149 per second)

Files:
    14866 created (94 per second)
        Creation alone: 10000 files (113 per second)
        Mixed with transactions: 4866 files (72 per second)
    4991 read (74 per second)
    0 appended (0 per second)
    14866 deleted (94 per second)
        Deletion alone: 9732 files (4866 per second)
        Mixed with transactions: 5134 files (76 per second)

Data:
    1428.03 megabytes read (9.10 megabytes per second)
    4253.60 megabytes written (27.09 megabytes per second)

做了snapshot之后的结果

pm>set number 10000
pm>set size 300000
pm>set transactions 10000
pm>run
Creating files...
Done
Performing transactions..........Done
Deleting files...Done
Time:
    725 seconds total
    145 seconds of transactions (68 per second)

Files:
    14866 created (20 per second)
        Creation alone: 10000 files (17 per second)
        Mixed with transactions: 4866 files (33 per second)
    4991 read (34 per second)
    0 appended (0 per second)
    14866 deleted (20 per second)
        Deletion alone: 9732 files (9732 per second)
        Mixed with transactions: 5134 files (35 per second)

Data:
    1428.03 megabytes read (1.97 megabytes per second)
    4253.60 megabytes written (5.87 megabytes per second)

dd顺序写

未做snapshot前的测试结果:

time dd if=/dev/zero of=file.l bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 47.5652 s, 86.1 MB/s

real    0m47.567s
user    0m0.308s
sys    0m12.073s

做了snapshot之后的测试结果:

time dd if=/dev/zero of=file.l bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 722.703 s, 5.7 MB/s

real    12m2.705s
user    0m0.252s
sys    0m14.653s

按理说，建立snapshot之后，中间是多了一层，但是也没有双重写入，为什么性能会相差几倍甚至十几倍呢？这是我百思不得其解的。询问了一些朋友，也没有发现有这样的情况，不过其他人却是没有使用RAID1这种IO性能比较低的架构。另外在我使用EMC的存储作为磁盘来做LVM的情况下，有无 snapshot的IO性能只相差了20%左右。所以我断定，可能是因为磁盘和RAID1的性能太差导致做了LVM snapshot之后，在低性能的情况下过早出现IO的瓶颈导致的。