4-浅谈binlog日志文件

1.MySQL binlog是个啥

• 之前我们说的redo log其实一种比较偏向物理的日志,记录对哪个数据中的什么记录做了什么修改
• 并且redo log属于innodb存储引擎特有的一个东西
• binlog也叫作归档日志,是一种偏向于逻辑性的日志文件,记录着对对某一行数据进行操作,操作后的值是什么
• binlog并不是innodb存储引擎特有的日志文件.binlog是属于MySQL server自己的日志文件

2.提交事务的同时也会写入binlog,这其中的执行器是一个非常核心的组件,负责跟innodb引擎配合完成一个sql语句在磁盘跟内存层面的更新操作

上图的1.2.3.4属于sql语句更新操作过程 5.6属于事务提交阶段操作

3.binlog的刷盘策略

通过sync-binlog参数来控制,其默认值为0,当binlog写入磁盘的时候不会直接进入磁盘,而是先进入os cache缓存,如果此时宕机,则会导致os cache数据丢失

但是如若sync-binlog值为1的话,在提交事务的同时会强制让其日志文件直接刷入binlog日志文件中去,此时哪怕是宕机也不怂,因为binlog日志文件中已经有了数据

4.redo log 跟 binlog的双重保险完成事务的提交

在我们将binlog写入磁盘之后,接着就会完成事务的最终提交,此时会将binlog的名字以及这次更新的binlog日志在文件中的位置写入到redo日志文件中去并且打上commit标记

5.在redo日志中打上commit标记有何意义?

• 其实就是保证redo日志跟binlog日志数据一致
• 因为如果系统在提交事务的时候宕机了(也就是图中5.6.7三个步骤),则binlog跟redo log的数据是不匹配的,此时innodb可以判定该次事务提交是失败的
• 必须是要在redo log中写入最终的事务并且打上了commit标记,然后此时事务提交成功,redo log中有本次更新对应的日志,binlog中也有本次更新对应的日志,此时redo 跟binlog才是完全一致的

6.后台IO线程随机将脏数据刷回磁盘

此时以及提交事务成功,buffer pool中已经将name将原来的zhangsan改成lisi了,但是此时的lisi还是脏数据,因为此时的磁盘文件name依旧是zhangsan并非lisi,所以此时就会有一个后台的IO线程,会在某一个时间段随机的将修改后的脏数据刷入磁盘文件

如果在刷脏数据的时候MySQL宕机了也没问题,因为redo log跟binlog都有日志记录,重启之后会按照redo日志去恢复之前的修改,也就是buffer pool中name=lisi,IO线程会静待时机将脏数据再次刷入磁盘中去

7.数据更新的流程

• 当你在执行更新操作的时候,每条sql语句都会更新buffer pool中的缓存数据.写undo redo等等步骤
• 在提交事务的时候,一定会将redo log刷入磁盘,binlog刷入磁盘并且完成在redo日志文件中的commit标记,最后一个IO线程会随机将buffer pool里的脏数据刷入到磁盘中去