基于binlog的事务恢复流程

资料来自于 阿里 数据库内核月报

两阶段提交

在这里插入图片描述
为什么需要两阶段提交即为什么binlog要在redolog之间?先使用redolog或者binlog为什么不行?

MySQL故障恢复流程

MySQL故障恢复启动时,会初始化储存引擎,这里讨InnoDB,InnoDB会读取redolog进行InnoDB的故障恢复,回滚prepare(同时肯定没有commit) 的事务,但是对于已经prepare的事务,但是未commit事务,会暂时挂起,保存到链表中,然后等待读取binlog,读取binlog后,由于已经prepare的事务但是没commit的事务,这里只有两种情况,一个是binlog写入完成,此时就可以根据已经写入的binlog来执行commit,另一种情况是binlog未写入,此时直接丢弃这条数据,不进行commit。

所以现在就很容易看出为什么要进行两阶段提交:

如果先写binlog 后写 redolog: 在写完binlog后崩溃,在事务进行恢复的时候,将无法扫描到这行,即redolog里没有关于这行的任何信息,自然也就不可能根据redolog去进行恢复,但是行后续如果根据binlog去恢复数据,此时就会造成恢复出来的数据(根据binlog)和被恢复的数据不同(根据redolog),此时将会造成数据不一致。

**如果先写redolog后写binlog:**此时redolog写完,崩溃,此时binloglog里没有,而后续恢复是按照redolog来的,此时将无法恢复这条数据,而使用binlog进行数据库的备份或者恢复,也会造成数据不一致。

使用两阶段提交解决了上面两个方法的数据不同步的问题:

上面两种情况问题都是崩溃后redolog和binlog数据不一致,而通过两阶段提交和基于binlog与redolo对比恢复解决了数据不一致的问题。

对于的可能出现的故障问题为:
redolog prepare后故障:此时binlog无记录,redolog prepare,恢复时按照redolog为prepare状态对比binlog,此时binlog无记录,该redolog记录被撤销,不执行。

binlog commit后故障:此时binlog有记录,redolog prepare,恢复时检测到binlog有,就直接继续执行commit。

即:通过两阶段提交来保证binlog、redolog数据恢复一致性

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 像素格子 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读