数据库日志回放过程

我是社区第2725位番薯,欢迎点我头像关注我哦~
我们看一段描述:一个看起来正确的过程,系统宕机后需要重启,重启过程中需要对事务涉及到的数据进行"整理",包括:宕机时刻尚未提交的事务对数据的修改需要回滚。实现整理的过程称之为"日志回放".通过从后向前回放UNDO LOG日志,直到找到commit点为止,这样就保证了数据一致性。    上面的过程看起来很完美。真的完美吗?问题出在这里:如果系统中同时有多个事务在执行,UNDO LOG中的commit点该如何定义呢?可能存在多个等待Commit的点。(继续之前考虑一下Global Serializability,多个commit点与此冲突吗?)
    实战:可以工作的过程
    方法1:系统重启回放日志,只需要从后往前扫描日志文件,对于所有没有commit的事务按照日志记录中的数据做回滚操作。这个方法肯定是可以工作的,其问题在于要求扫描所有commit日志,代价不菲。
    方法2:使用Checkpoint,拉起一个大栅栏。Checkpoint可以看做是对引言中"commit点"的展开,它好比一个较宽的栅栏(fence),将所有已经开始、尚未commit的事务都记录下来,等待这些事务完成之后再在日志中写入一条"在这个栅栏架起来之前的那些状态一致了"的标记。
    为什么是"架起来之前的"呢?因为在架起栅栏后有一段等待事务完成时间,这段时间里会有新的事务发起,他们也会继续写日志,对于这些事务Checkpoint不关注。
    生成checkpoint的过程:
    1. 在日志中写下CREATE_CKPT(T1,T2,,Tn),其中Ti表示写入CREATE_CKPT之前尚未完成的事务
    2. 等待T1~Tn这些事务完成。在等待过程中可能会有新的事务写日志。
    3. 在日志中写入END_CKPT
    日志回放过程:
    从后往前扫描日志,如果先遇到END_CKPT,那么说明CREATE_CKPT中记录的T1~Tn这些事务都已经完成,将日志回放至CREATE_CKPT处即可。之前的日志均可以丢弃。如果先遇到CREATE_CKPT,那么说明T1~Tn这些事务可能还有没完成的,那么为了保证Global Serialization,将日志回滚到T1~Tn中最早出现的那一条之前即可。例如T3是T1~Tn中最先开始的事务,则将事务回滚检查做到T3之前即可,因为T3前的所有数据均已经确保Commit了。

发表于 2012-4-11 13:18:59
刚开始学习,还没弄明白
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

1回帖数 1关注人数 5567浏览人数
最后回复于:2012-4-11 13:18

返回顶部 返回列表