Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3173532
  • 博文数量: 251
  • 博客积分: 11197
  • 博客等级: 上将
  • 技术积分: 6862
  • 用 户 组: 普通用户
  • 注册时间: 2008-12-05 14:41
个人简介

@HUST张友东 work@taobao zyd_com@126.com

文章分类

全部博文(251)

文章存档

2014年(10)

2013年(20)

2012年(22)

2011年(74)

2010年(98)

2009年(27)

分类: 数据库开发技术

2013-07-22 08:56:27

数据库通常借助日志来实现事务,常见的有undo log、redo log,undo/redo log都能保证事务特性,这里主要是原子性和持久性,即事务相关的操作,要么全做,要么不做,并且修改的数据能得到持久化。

假设数据库在操作时,按如下约定记录日志:

1. 事务开始时,记录START T
2. 事务修改时,记录(T,x,v),说明事务T操作对象x,x的值为v 
3. 事务结束时,记录COMMIT T 

undo log原理

undo log是把所有没有COMMIT的事务回滚到事务开始前的状态,系统崩溃时,可能有些事务还没有COMMIT,在系统恢复时,这些没有COMMIT的事务就需要借助undo log来进行回滚。

使用undo log时,要求:

1. 记录修改日志时(redo log),(T,x,v)中v为x修改前的值,这样才能借助这条日志来回滚;
2. 事务提交后,必须在事务的所有修改(包括记录的修改日志)都持久化后才能写COMMIT T日志;这样才能保证,宕机恢复时,已经COMMIT的事务的所有修改都已经持久化,不需要回滚。 

使用undo log时事务执行顺序

1. 记录START T 
2. 记录需要修改的记录的旧值(要求持久化)
3. 根据事务的需要更新数据库(要求持久化)
4. 记录COMMIT T 

使用undo log进行宕机回滚

1. 扫描日志,找出所有已经START,还没有COMMIT的事务。
2. 针对所有未COMMIT的日志,根据redo log来进行回滚。 

如果数据库访问很多,日志量也会很大,宕机恢复时,回滚的工作量也就很大,为了加快回滚,可以通过checkpoint机制来加速回滚,

  1. 在日志中记录checkpoint_start (T1,T2…Tn) (Tx代表做checkpoint时,正在进行还未COMMIT的事务)
  2. 等待所有正在进行的事务(T1~Tn)COMMIT
  3. 在日志中记录checkpoint_end

借助checkpoint来进行回滚

从后往前,扫描undo log
1,如果先遇到checkpoint_start, 则将checkpoint_start之后的所有未提交的事务进行回滚;
2. 如果先遇到checkpoint_end, 则将前一个checkpoint_start之后所有未提交的事务进行回滚;(在checkpoint的过程中,可能有很多新的事务START或者COMMIT)。 

使用undo log,在写COMMIT日志时,要求redo log以及事务的所有修改都必须已经持久化,这种做法通常很影响性能。

redo log原理

redo log是指在回放日志的时候把已经COMMIT的事务重做一遍,对于没有commit的事务按照abort处理,不进行任何操作。

使用redo log时,要求:

1. 记录redo log时,(T,x,v)中的v必须是x修改后的值,否则不能通过redo log来恢复已经COMMIT的事务。
2. 写COMMIT T日志之前,事务的修改不能进行持久化,否则恢复时,对于未COMMIT的操作,可能有数据已经修改,但重放redo log不会对该事务做任何处理,从而不能保证事务的原子性。 

使用redo log时事务执行顺序

1. 记录START T
2. 记录事务需要修改记录的新值(要求持久化)
3. 记录COMMIT T(要求持久化)
4. 将事务相关的修改写入数据库 

使用redo log重做事务

1. 扫描日志,找到所有已经COMMIT的事务;
2. 对于已经COMMIT的事务,根据redo log重做事务; 

在日志中使用checkpoint

1. 在日志中记录checkpoint_start (T1,T2...Tn) (Tx代表做checkpoint时,正在进行还未COMMIT的日志)
2. 将所有已提交的事务的更改进行持久化;
3. 在日志中记录checkpoint_end 

根据checkpoint来加速恢复

从后往前,扫描redo log
1,如果先遇到checkpoint_start, 则把T1~Tn以及checkpoint_start之后的所有已经COMMIT的事务进行重做;
2. 如果先遇到checkpoint_end, 则T1~Tn以及前一个checkpoint_start之后所有已经COMMIT的事务进行重做; 

与undo log类似,在使用时对持久化以及事务操作顺序的要求都比较高,可以将两者结合起来使用,在恢复时,对于已经COMMIT的事务使用redo log进行重做,对于没有COMMIT的事务,使用undo log进行回滚。redo/undo log结合起来使用时,要求同时记录操作修改前和修改后的值,如(T,x,v,w),v为x修改前的值,w为x修改后的值,具体操作顺序为:

1. 记录START T
2. 记录修改日志(T,x,v,w)(要求持久化,其中v用于undo,w用于redo)
3. 更新数据库
4. 记录 COMMIT T 

4和3的操作顺序没有严格要求,并且都不要求持久化;因为如果宕机时4已经持久化,则恢复时可通过redo log来重做;如果宕机时4未持久化,则恢复时可通过undo log来回滚;在处理checkpoint时,可采用与redo log相同的处理方式。

阅读(14296) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册