LVM 快照(snapshot)的第二种用法

之前我已总结了 LVM 快照的第一种用法: 利用 LVM 在线抓取 MySQL 数据库快照, 也可以扩展到任何需要在线生成磁盘快照的应用. 自 LVM 2.0 以来, 镜像分区不只是只读的, 而且可写. 而写入快照分区的一种应用就是造”沙盒(sandbox)”, 在 Xen VM 环境的具体步骤如下:

1, 假设供测试的虚拟机 test, 分区是 /dev/vm/test-disk, 为其生成 10GB 快照分区 test-ss:

lvcreate -s -n test-ss -L10G /dev/vm/test-disk

2, 将 test 虚拟机关机, 可以

ssh [email protected] “shutdown -h now”

或者

xm shutdown test

3, 复制 /etc/xen/test.conf 到 test-s1.conf, 并将磁盘分区 /dev/vm/test-disk 替换为 /dev/vm/test-ss, 就是用快照分区作为 VM 的系统分区

4, 启动沙盒: xm create test-s1.conf

5, 可以用沙盒进行各种天诛地灭的测试项目了

6, 如何结果不如意, 只需要把快照分区删除就行了, 因为源磁盘分区并未改动.

lvremove /dev/vm/test-ss

如果结果如意, 可以把镜像上的改动合并入源

lvconvert –merge /dev/vm/test/ss

🙂

利用 LVM 在线抓取 MySQL 数据库快照

小试分身 MySQL Replication, 上次是按照 MySQL 教程做的, 比较死板(或者说, 安全), 但需要锁住数据库, 也就是说, 用户一端的感觉就是服务器出问题了… 而如果通知用户服务器要下线一段时间的话, 又会引起不明真相的用户的莫名猜疑. 那么就需要一种在几秒中之内完成生成镜像的操作, 于是我就想到了 LVM snapshot.

Google 了一番, 我看到已经有成功先例了, 步骤如下:

1, 确认 MySQL 的数据区(缺省 /var/lib/mysql) 是在 LVM 上, 假设是 /dev/VOLUME_GROUP/data
2, 开一个 MySQL session, 执行并记录 show master status 的输出:

flush tables with read lock;
show master status;

3, 在另一个 terminal 执行:

lvcreate -s -n snapshot_name -L5G /dev/VOLUME_GROUP/data

4, 在步骤2的 session 里继续:

unlock tables;

5, /dev/VOLUME_GROUP/snapshot_name 里面就是需要的快照了, 之后将快照复制到从属服务器上然后开启 replication 即可, 这里就略过了.

步骤2/3/4应该可以写到一个 shell script 里面, 这样数据库锁住的时间应该能在3~5秒之内, 用户可能会感觉数据更新时慢了一些, 希望不会有人因为几秒钟的耽搁而花20分钟来投诉吧 🙂

To Duplicate/Backup a Xen VM in a Logical Volume

技术笔记. 请忽略 🙂

0, If you are to duplicate, create VMs on destination server, just to create conf files and logical volumes for VMs and hold the place for source VMs.

#xen-create-image –hostname [HOSTNAME] –ip [IP] –vcpus 2 –pygrub –dist squeeze

1, Create an LVM snapshot for the VM’s logical volume.

#lvcreate -L[SIZE] -s -n [SNAPSHOTNAME] /dev/[VOLUMEGROUP]/[LOGICALVOLUME]

2, Shutdown the VM if optional. Login the VM and shut down or:

#xm shutdown [VM]

3, Copy the snapshot over to destination server. Login to the source server and do

#dd bs=4M if=/dev/[VOLUMEGROUP]/[SNAPSHOTNAME] | gzip -1 – | ssh [USER]@[DESTINATION] dd bs=4M of=[/PATH]/tmp.gz

3.1, If step 3 is successful, you can remove the snapshot optionally.

#lvremove /dev/[VOLUMEGROUP]/[SNAPSHOTNAME]

4, Restore the volume image to the target logical volume on destination server. Better make the target volume bigger than the source volume.

#dd bs=4M if=[/PATH]/tmp.gz | gunzip -1 – | dd bs=4M of=/dev/[TARGETVOLUMEGROUP]/[TARGETLOGICALVOLUME]

4.1, If the target volume is bigger than the source volume(which is recommended), check and resize:

#e2fsck -f /dev/[TARGETVOLUMEGROUP]/[TARGETLOGICALVOLUME]
#resize2fs /dev/[TARGETVOLUMEGROUP]/[TARGETLOGICALVOLUME]

5, Mount target volume for modifications such as IP, etc. And un-mount after this.

#mount /dev/[TARGETVOLUMEGROUP]/[TARGETLOGICALVOLUME] /[MOUNTPATH]
#umount /dev/[TARGETVOLUMEGROUP]/[TARGETLOGICALVOLUME]

6, Compare both source and destination VM configuration files if there’s different booting methods.

7, Boot up the cloned VMs and test.

#xm create [HOSTNAME].cfg
#xm top

🙂