MySQL: 4 深入了解binlogredo log

Posted 鮀城小帅

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL: 4 深入了解binlogredo log相关的知识,希望对你有一定的参考价值。

1.redo日志刷盘策略的最佳选择

        在上一小节中,提到redo日志有三种刷盘策略,通常建议是设置为1。

        也就是说,提交事务的时候,redo日志必须是刷入磁盘文件里的。这样可以严格的保证提交事务之后,数据是绝对不会丢的,因为有redo日志在磁盘文件里可以恢复你的所有修改。

        如果选择0的话,可能在提交事务之后,mysql宕机,那么redo日志没有刷盘,导致内存里的redo日志丢失,你所提交的事务更新的数据就丢失了;

        如果选择2的话,如果机器宕机,由于在提交事务的时候,redo日志进入 os cache了,还未进入磁盘文件,此时机器宕机依旧会导致 os cache里的redo日志丢失。

        所以,建议redo日志刷盘策略设置为1,保证事务提交之后,数据绝对不能丢失。

2.MySQL binlog

        前面说过的redo log是属于InnoDB存储引擎特有的一个东西。其主要偏向物理性质的重做日志,它里面记录的是类似这样的东西,“对哪个数据页中的什么记录,做了个什么修改”。

        而binlog叫做归档日志,它里面记录的是偏向于逻辑性的日志,类似于“对users表中的id=10的一行数据做了更新操作,更新以后的值是什么”。

        binlog不是InnoDB存储引擎特有的日志文件,是属于mysql server自己的日志文件。

3.提交事务的时候,同时会写入binlog

        前面说过,在提交事务的时候,会把redo log 日志写入磁盘文件中去。

        其实在提交事务的时候,同时还会把这次更新对应的binlog日志写入到磁盘文件中去。

如图,这里加入了跟InnoDB存储引擎进行交互的组件加入了之前提过的执行器这个组件,它会负责跟InnoDB进行交互,包括从磁盘里加载数据到Buffer Pool中进行缓存,包括写入undo日志,包括更新Buffer Pool里的数据,以及写入redo log buffer, redo log 刷入磁盘,写binlog ,等等。

两个阶段:

  1. 上图中的1、2、3、4几个步骤是执行该更新语句的时候干的事,是执行SQL的阶段。
  2. 然后上图中的5、6两个步骤,是从提交事务开始的,属于提交事务的阶段了。

4.binlog日志的刷盘策略分析

binlog日志也有不同的刷盘策略,通过 sync_binlog参数去控制binlog的刷盘策略。

        其默认值是0,此时你把binlog写入磁盘的时候,其实不是直接进入磁盘文件,而是进入os cache内存缓存。也就是说,此时机器宕机,那么在 os cache里的binlog日志是会丢失的。

如果把sync_binlog参数设置为1的话,那么此时会强制在提交事务的时候,把binlog直接写入到磁盘文件里去,那么这样提交事务之后,哪怕机器宕机,磁盘上的binlog是不会丢失的。

5.基于binlog和redo log 完成事务的提交

当我们把binlog写入磁盘文件之后,接着就会完成最终的事务提交,此时会把本次更新对应的binlog文件名称和这次更新的binlog日志在文件里的位置,都写入到redo log日志文件里去,同时在 redo log日志文件里写入一个commit标记。

在完成了这个事情之后,才算最终完成了事务的提交。

6.最后一步在redo日志中写入commit标记的意义是什么?

最后在redo日志中写入commit标记的意义是什么?

答:它是用来保持redo log日志与binlog日志一致的。

案例分析讲解

假设在提交事务的时候,一共有上图中的5、6、7三个步骤,必须是三个步骤都执行完毕,才算是提交了事务,那么在我们刚完成步骤5的时候也就是redo log刚刷入磁盘文件的时候,mysql宕机了,此时怎么办?

这个时候因为没有最终的事务commit标记在redo日志里,所以此次事务可以判定为不成功。不会说redo日志文件里有这次更新的日志,但是binlog日志文件里没有这次更新的日志,不会出现数据不一致的问题。

如果要是完成步骤6的时候,也就是binlog写入磁盘了,此时mysql宕机了,怎么办?

同理,因为没有redo log中的最终commit标记,因此此时事务提交也是失败的。

必须是在redo log中写入最终的事务commit标记了,然后此时事务提交成功,而且redo log里有本次更新对应的日志,binlog 里也有本次更新对应的日志,redo log和binlog 完全是一致的。

7.后台IO线程随机将内存更新后的脏数据刷回磁盘

一次更新的事务提交成功,其实质上只是将数据更新到缓存,也就是说缓存与磁盘存在不一致,这是脏数据。而这是需要将脏数据刷回磁盘,以保持同步的。

所以mysql有一个后台的IO线程,会在事务提交之后某个时间里,随机的把内存buffer pool中的修改后的脏数据给刷回到磁盘上的数据文件里去。

当上图中的IO线程把buffer pool里的修改后的脏数据刷回磁盘之后,磁盘上的数据才会跟内存里一样,都是name=lisi这个修改以后的值了。

在你IO线程把脏数据刷回磁盘之前,哪怕mysql宕机崩溃也没关系,因为重启之后,会根据redo日志恢复之前提交事务做过的修改到内存里去,就是id=10的数据的name修改为了lisi,然后等适当时机,IO线程自然还是会把这个修改后的数据刷到磁盘上的数据文件里去的。

8.基于更新数据的流程,总结一下InnoDB存储引擎的架构原理

在一次更新数据的流程中,InnoDB存储引擎主要就是包含了一些buffer pool、redo log buffer等内存里的缓存数据,同时还包含了一些undo日志文件,redo日志文件等东西,同时mysql server自己还有binlog日志文件。

在执行更新的时候,每条SQL语句,都会对应修改buffer pool里的缓存数据、写undo日志、写redo pool buffer几个步骤;

但是当你提交事务的时候,一定会把redo log 刷入磁盘,binlog刷入磁盘,完成redo log中的事务commit标记;最后后台的IO线程会随机的把buffer pool里的脏数据刷入磁盘里去。

9.思考:

(1)执行更新操作的时候,为什么不能执行修改磁盘上的数据?

(2)为什么MySQL在更新数据的时候,要大费周章的搞这么多事情,包括buffer pool、redo log、undo log、binlog、事务提交、脏数据。引入了一大堆的概念,有复杂的流程和步骤。

(3)为什么它反而最关键的修改磁盘里的数据,要通过IO线程不定时的去执行?

(4)为什么它不干脆直接每次执行SQL语句,直接就更新磁盘里的数据得了?

以上是关于MySQL: 4 深入了解binlogredo log的主要内容,如果未能解决你的问题,请参考以下文章

必须了解的mysql三大日志-binlogredo log和undo log

3000帧动画图解MySQL为什么需要binlogredo log和undo log

刨析 MySQL 三大日志:binlogredo log 和 undo log

刨析 MySQL 三大日志:binlogredo log 和 undo log

3000帧动画图解MySQL为什么需要binlogredo log和undo log

Mysql 回表SQL优化四种隔离级别三大日志binlogredo logundo log