MySQL里redolog和binlog数据一致性小结

刚看了看MySQL的日志相关的东西,主要是redo-log和bin-log,虽然平时工作当中用不到,思考学习了一下,简单做下总结

比如做一个更新操作,主键ID为2的记录,字段a递增1

这里取了两个时间点,TimeA是写入redolog未commit,TimeB是写入了binlog

Binlog

TimeA的时候崩溃,redolog虽然写入了,但是没提交,所以崩溃恢复的时候,事务会回滚,未更新成功;备份恢复的时候,binlog由于并没有写入,因此同样未更新成功;数据一致

TimeB的时候崩溃,redolog写入了,此时虽然没有commit,但是通过一个关联字段检查binlog,发现是完整的,因此崩溃恢复的时候还是会提交事务,更新a=a+1;binlog写入了,因此恢复的时候,会恢复更新后的结果,也就是a=a+1;数据一致

 

可以看到这里redolog整个写入的过程被分成了两部分,先写入redolog,但是没提交事务,然后写binlog到磁盘,最后才提交redolog才算完成

除了这种方式,可以看看另两种方案,要么binlog先写完,然后redolog;要么redolog先写完提交,然后binlog

第一种情况

UntitledImage

TimeA的时候崩溃,redolog没写入,因此异常恢复的时候恢复的是a;binlog写入了,因此备份恢复的时候,恢复的是a=a+1;这样就导致两者数据不一致

TimeB的时候崩溃,redolog已写入,但是没提交,发现binlog完整,因此异常恢复的时候,会自动提交,从而恢复的是a=a+1;binlog写入了,因此备份恢复的时候,恢复的是a=a+1;数据一致

 

第二种情况

UntitledImage

TimeA的时候崩溃,redolog写入了,但是没提交,也找不到完整的binlog,因此异常恢复的时候,会回滚,恢复的是a;binlog没写入,因此备份恢复的时候,恢复的是a;数据一致

TimeB的时候崩溃,redolog写入了并且已经提交,因此异常恢复的时候,恢复的是a=a+1;binlog没写入,因此备份恢复的时候,恢复的是a;数据不一致

 

综上可以看到,这两种方式,都会导致恢复的数据不一致

发表评论