MySQL中的redo日志文件.pdfVIP

MySQL中的redo⽇志⽂件

MySQL中的redo⽇志⽂件

MySQL中有三种⽇志⽂件，redolog、binlog、undolog。redolog是存储引擎层(innodb)⽣成的⽇志，主要为了保证数据的可靠性；bin

log是MySQL数据库层⾯上⽣成的⽇志，主要⽤于pointintime恢复和主从复制。undolog主要⽤于事务的回滚(undolog记录的是每个修

改操作的逆操作)和⼀致性⾮锁定读(undolog回滚⾏记录到某种特定的版本MVCC多版本并发控制)。

redolog和undolog都是存储引擎层⾯上⽣成的⽇志，并且都记录了数据的修改：只不过redolog记录的是物理级别上的页修改操作，⽐

如页号xxx、偏移量yyy写⼊了zzz数据；⽽undolog记录的是逻辑操作⽇志，⽐如对某⼀⾏数据进⾏了INSERT语句操作，那么undolog就

记录⼀条与之相反的DELETE操作。

redolog作⽤保证事务的持久性

MySQL作为⼀个存储系统，为了保证数据的可靠性，最终得落盘。但是，⼜为了数据写⼊的速度，需要引⼊基于内存的缓冲池。其实不⽌

MySQL，这种引⼊缓冲来解决速度问题的思想⽆处不在。既然数据是先缓存在缓冲池中，然后再以某种⽅式刷新到磁盘，那么就存在因宕

机导致的缓冲池中的数据丢失，为了解决这种情况下的数据丢失问题，引⼊了redolog。在其他存储系统，⽐如Elasticsearch中，也有类似

的机制，叫translog。

但是⼀般讨论数据写⼊时，在MySQL中，⼀般叫事务操作，根据事务的ACID特性，如何保证⼀个事务提交后Durability的保证？⽽这就是

redolog的作⽤。当向MySQL写⽤户数据时，先写redolog，然后redolog根据某种⽅式持久化到磁盘，变成redologfile，⽤户数据则

在buffer中(⽐如数据页、索引页)。如果发⽣宕机，则读取磁盘上的redologfile进⾏数据的恢复。从这个⾓度来说，MySQL事务的持久性

是通过redolog来实现的。

redolog写⼊磁盘

在事务运⾏过程中，会不断地产⽣redolog，这些redolog会先定⼊redologbuffer中，然后再将redologbuffer中的数据以某些⽅式顺序

地写⼊到磁盘（各个操作的redolog汇总到redologbuffer，再由redologbuffer统⼀写磁盘，就能做到顺序写了）。这些⽅式有：

MySQLmaster线程周期性任务每秒⼀次，将redologbuffer刷新到磁盘(即使这个事务尚未提交)

MySQLmaster线程周期性任务每10秒⼀次，将redologbuffer刷新到磁盘

当redologbuffersize剩余空间⼩于1/2时(innodb_log_buffer_size参数)，将redologbuffer刷新到磁盘

当redologfile⼤⼩已经达到某个域值快要不可⽤时（⽇志⽂件组轮流写⽂件），触发async/syncflushcheckpoint，及时将⼀些脏

页刷新到磁盘，并同时将redologbuffer刷新到磁盘，然后更新redologfile相应的logsequencenumber值。

redologbuffer的刷新到磁盘的时机由参数innodb_flush_log_at_trx_commit参数控制，可取的值有：0、1、2：

0由master线程周期性任务刷新

1在事务commit时redologbuffer同步写⼊disk，伴随fsync调⽤

2将redolog⽇志数据异步写⼊disk，即只写到⽂件系统缓存中，在事务成功提交后并不能保证redolog数据⼀定存储到磁盘上了

redolog写⼊磁盘时，是以扇区⼤⼩512B写⼊的，保证每次写都能写⼊成功，不需要有doublewrite机制。

redologbuffer与数据页、索引页、何时刷盘的区别？

Innodb存储引擎基于缓冲池来平衡CPU与磁盘之间的速度差距，提⾼数据库的性能。数据页、索引页属于缓冲池的⼀部分，⽽redolog

buffer其实也是⼀块内存结构。redolog的作⽤是⽤于故障恢