数据库事务的checkpoint机制实现
上一章的结尾我们留下了一个问题,就是在上一章所介绍的模型中,恢复管理器必须要通过全篇扫描整个undolog进行日志恢复,这样做显然是没有太大必要的,因为系统中断肯定是在最后几个事务受到影响,前面的事务应该已经完成commit或者rollback了,不会出现abort的情况,那我们如何知道哪些事务受到了影响呢,如果我们知道了哪一些事务受到了影响,那我们就可以不用全篇进行扫描,而仅仅扫描很小的一部分就可以了。下面就介绍下,数据库如何知道哪些事务受到了影响,数据库为了得到这个目的,引入了检查点(checkpoint)这个概念。
checkpoint 检查点
checkpoint,即检查点。在undolog中写入检查点,表示在checkpoint前的事务都已经完成commit或者rollback了,也就是检查点前面的事务已经不存在数据一致性的问题了。那这个checkpoint如何去实现呢。其实实现的机制很简单,就是周期性的往undolog里面写入。当然这个写入肯定不是随随便便的往里写,在往里写的时候,肯定要检查前面的事务是否完成。
这个时候就会带来一个问题,因为数据库是一直在运行的,也就是事务是在不断启动的,同时可能有n个事务已经处于开始状态。而在检查点往里写的时候,可能又有新的事务启动了,如果让检查点一直等到没有新的事务启动而且前面所有的事务又都提交过了估计很难,那基本检查点就不用往里写了。所以,在这种情况下,只能是在检查点往里写的时候,停止接受新事务,等待已启动的事务提交完毕,然后检查点写入完毕。然后继续接受新事务。类似于这样: 例如,现在有T1 T2两个事务,则undolog中写入:
undolog |
---|
start T1 |
<T1,A,x> |
start T2 |
<T2,B,y> |
这时到了检查点的周期,要往里写入检查点了,就得等到T1,T2全部提交完毕,然后写入检查点chkpoint。也就是如果现在有一个T3要开启,是无法开启的。系统处于夯住状态。写入完后,开启T3,日志记录如下:
undolog |
---|
start T1 |
<T1,A,x> |
start T2 |
<T2,B,y> |
end T1 |
end T2 |
chkpoint |
start T3 |
这时候,如果系统挂掉了,故障恢复管理器会从undolog的尾部向前进行扫描,扫描到checkpoint后,就不会往前扫描了,因为前面的事务都已经提交过了,不存在数据一致性问题。所以只需要从checkpoint开始重做即可。
这样固然是好,省掉了需要undolog从头开始扫描的麻烦,但是这样做的缺点也很明显,那就是在写入checkpoint的过程中,系统是出于夯住状态的,所有的写入都要暂停。那能否有一种更好的方法既可以写入checkpoint又不需要系统暂停呢,必须的,当然有,这就是下面要讲的非静态检查点。
非静态检查点
非静态检查点是相对于静态检查点而来的,上文中所提到的就属于静态检查点,因为在检查点写入的同时,系统是不能写入的。而非静态检查点的引入,就是要解决这个问题。
非静态检查点的策略是在写入chkpoint的同时,会记录下当前活跃的事务。比如,当前状态下,T1和T2都是活跃状态,那么undolog中会被写入start checkpoint(T1,T2),这时整体系统仍然是正常写入的,也就是说在这条log写入后,仍然可以继续开启其他事务。当T1,T2完成后,会写入end checkpoint的记录。例如如下记录:
undolog |
---|
start T1 |
<T1,A,x> |
start T2 |
<T2,B,y> |
start checkpoint(T1,T2) |
start T3 |
end T1 |
end T2 |
end chkpoint |
start checkpoint(T3) |
end T3 |
end chkpoint |
上面这个日志记录就是,在T1,T2开始后,undolog中写入了start checkpoint(T1,T2)的检查点,而这时仍然是可以接受其他事务的开始的,这时有了T3事务的开启。
通过这种机制,可以有效避免在检查点写入时需要停掉服务的弊端,但现在问题又来了,这样写检查点固然是好,但恢复管理器如何通过这样的undolog去进行数据恢复操作呢?因为,如果检查点是静止的,那找到checkpoint后,就不必再往前找了,而现在不一样了,因为找到end checkpoint后,前面仍可能有未完成的事务,那这时数据恢复是如何恢复的呢?
在这种情况下,数据库宕机后,恢复管理器仍然会从尾往前进行扫描undolog,如果遇到了“end chkpoint”,这时并不代表checkpoint前所有的事务都已经提交了,但我们可以知道,所有未提交的事务都是在上一个start checkpoint之后,所以会继续往前找,一直找到start checkpoint,找到start checkpoint后,比如是start checkpoint(T1,T2),因为先前已经找到了end chkpoint,所以T1,T2这两个事务已经可以保证数据一致性了,需要重做的就是在start checpoint(T1,T2)到end chkpoint间的这一些非T1,T2事务,这些是需要重做的,所以要把这些进行重做。
还有另外一种情况,就是恢复管理器在扫描时,先遇到了start checkpoint(T1,T2)的日志,在这种情况下,我们首先知道了T1,T2或许是未完成的事务,那这时需要在start checkpoint之后找到是否有某个事务的end语句,如果有,说明这个事务是完成了,如果没有,就说明没有完成,那就要从check point再往后寻找,找到这个事务的start,然后从start之后往后重做。说得比较罗嗦,我们上个例子来说明下这种情况。
例如,数据库宕机后,开始扫描undolog,得到以下片段:
undolog |
---|
start T1 |
<T1,A,15> |
start T2 |
<T2,B,39> |
start checkpoint(T1,T2) |
start T3 |
<T3,C,40> |
end T1 |
<T3,C,50> |
这时,恢复管理器拿到这个片段后进行扫描,在遇到end chkpoint前遇到了start checkpoint(T1,T2),这说明了,T1,T2是可能未完成事务的,而且在这之前还遇到了T3的start,没有end T3,也没有任何T3的检查点的开始,这说明了T3一定是未完成事务的,所以T3一定是要重做的。先前为什么说T1,T2是可能未完成事务的呢?因为遇到了start checkpoint(T1,T2),没有遇到end chkpoint,并不代表T1和T2就一定是未完成的,可能有一个已经commit过了,因为两个都没有commit,所以才导致了没有end chkpoint,所以这时找start下面的日志,发现了“end T1”,说明了T1的事务是已经完成了的。那只需要找T2的开启然后开始重做就可以了,然后就通过start checkpoint(T1,T2)再往上找,找到了start T2,然后开始重做T2,也就是这个日志里,T2和T3是需要重做的,然后重做掉。 (注:刚才先说了做T3,然后有说了重做T2,并不代表真正的顺序就是这样,实际上恢复管理器是先分析出需要重做的事务,然后一块做掉的。)
推荐阅读
-
主选择机制的 ETCD 分布式锁实现(Golang 实现)
-
由于 "LOG_BACKUP",数据库 "xxx "的事务日志已满。
-
连接达蒙数据库的节点实现
-
[Transfer] 简单论坛后台数据库的设计与实现
-
Java 教程 4 数据库的高级功能 11 事务学习 猴子乐园原创
-
什么是 Spring 的事务?它们与数据库事务相同吗?
-
什么是数据库中的事务,它有哪些属性?
-
什么是数据库事物?为什么需要数据库事物,事物有哪些特征?事物的隔离级别是什么?-1.什么是数据库事务? 1.事务是作为一个逻辑单元执行的一系列操作。一个逻辑工作单元必须具备四个属性,即ACID(原子性、一致性、隔离性和持久性)属性,只有这样才能成为事务: 原子性 2.事务必须是一个原子工作单元;它的数据修改要么全部执行,要么全部不执行。 一致性 3.事务完成时,所有数据必须保持一致。在相关数据库中,所有规则都必须适用于事务的修改,以保持所有数据的完整性。事务结束时,所有内部数据结构(如 B 树索引或双向链接表)必须正确无误。 隔离 4.并发事务的修改必须与其他并发事务的修改隔离。一个事务会在另一个并发事务修改之前或之后查看某一状态下的数据,而不会查看中间状态下的数据。这就是所谓的可序列化,因为它允许重新加载起始数据和重放一系列事务,从而使数据最终处于与原始事务执行时相同的状态。 持久性 5.事务完成后,它对系统的影响是永久性的。即使在系统发生故障的情况下,修改也会保留。 2. 为什么需要数据库事物,事物有哪些特征? 事物对数据库的作用是对数据进行一系列操作,要么全部成功,要么全部失败,防止出现中间状态,确保数据库中的数据始终处于正确、和谐的状态。 特征:原子性、一致性、隔离性、持久性,以及其他特征 原子性(Atomicity):所有操作在事务开始后,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出现错误时,会回滚到事务开始前的状态,所有操作就像没有发生一样。也就是说,事务是一个不可分割的整体,就像化学中的原子一样,是物质的基本单位。 一致性(Consistency):在事务开始之前和结束之后,数据库的完整性约束都没有被破坏。例如,如果 A 转钱给 B,A 不可能扣除这笔钱,但 B 却没有收到这笔钱。 隔离:在同一时间内,只允许一个事务请求相同的数据,不同事务之间没有干扰。例如,甲正在从一张银行卡上取款,在甲取款过程结束之前,乙不能向这张卡转账。 持久性(耐用性):事务完成后,事务对数据库的所有更新都将保存到数据库中,无法回滚 3.事务的隔离级别有哪些? 数据库事务有四种隔离级别,从低到高分别是未提交读取(Read uncommitted)、已提交读取(Read committed)、可重复读取(Repeatable read)、可序列化(Serializable)。此外,事务的并发操作中可能会出现脏读、不可重复读、幽灵读等情况。事务并发问题 脏读:事务 A 读取事务 B 更新的数据,然后事务 B 回滚操作,那么事务 A 读取的数据就是脏数据。 不可重复读取:事务 A 多次读取同一数据,事务 B 在事务 A 多次读取期间更新并提交数据,导致事务 A 多次读取同一数据时结果不一致。 幻影读取:系统管理员 A 将数据库中所有学生的具体分数改为 ABCDE 等级,但系统管理员 B 在此时插入了具体分数的记录,当系统管理员 A 更改结束后发现仍有一条记录未被更改,仿佛发生了幻觉,这称为幻影读取。 小结:不可重复读和幻读容易混淆,不可重复读侧重于修改,幻读侧重于增删。解决不可重复读问题只需锁定满足条件的行,解决幻读问题则需要锁定表 MySQL 事务隔离级别
-
详细了解数据库中的事务管理 - II:事务的四个特点
-
基于 flask_login 的 Flask 实现登录、验证码 - 数据库模型