Chinaunix首页 | 论坛 | 博客
  • 博客访问: 297739
  • 博文数量: 240
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 50
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-04 18:14
文章分类

全部博文(240)

文章存档

2017年(8)

2014年(4)

2013年(15)

2012年(4)

2011年(14)

2010年(55)

2009年(140)

我的朋友

分类: LINUX

2010-06-23 13:38:19

Logical Volume Manager (LVM)提供了对任意一个Logical Volume(LV)做“快照”(snapshot)的功能,以此来获得一个分区的状态一致性备份。

在某一个状态下做备份的时候,可能有应用正在访问某一个文件或者数据库,这就是使得备份的时候文件处于一个状态,而备份完后,文件却处于另外一个状态,从而造成备份的非一致性,这种状态恢复数据库数据几乎不会成功。

状态的解决办法是将其分区挂载为只读,然后通过数据库的表级别锁定(table-level write locks)甚至停止数据库来备份数据。所有这些方法无意严重影响了服务的可用性。使用LVM snapshot既可以获得一致性备份,又不会影响服务器的可用性。

要提醒一点是,snapshot这种方法仅对LVM有效,对于非LVM文件系统无效。

snapshot的实现有多种方式(参考文章最后的连接),这里说说LVM中snapshot的“写时复制”(copy on write) 的实现方法。

当一个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

下面的图也许可以比较容易了解CoW的原理:

LVM snapshot简述

 

采取CoW实现方式时,snapshot的大小并不需要和原始卷一样大,其大小仅仅只需要考虑两个方面:从shapshot创建到释放这段时间内,估计块的改变量有多大;数据更新的频率。一旦 snapshot的空间记录满了原始卷块变换的信息,那么这个snapshot立刻被释放,从而无法使用,从而导致这个snapshot无效。所以,非常重要的一点,一定要在snapshot的生命周期里,做完你需要做得事情。当然,如果你的snapshot大小和原始卷一样大,甚至还要大,那它的寿命就是“与天齐寿”了。

阅读(741) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~