redo log称为重做日志,用来保证事务的原子性和持久性。
redo log通常是无力日志,记录的是页的物理修改操作。
其包含两部分:一是内存中的重做日志缓冲(redo log buffer);二是重做日志文件(redo log file)。
在InnoDB存储引擎中,通过FLC(Force Log at Commit)机制实现事务的持久性。
即当事务提交时,必须先将素有的日志写入到重做日志文件进行吃就好,待事务的Commit操作完成才算完成。
redo log基本上都是顺序写的,在数据库运行时不需要多redo log的文件进行读取操作。
这里有个细节,重做日志日文件打开时没有使用O_DIRECT选项,因此重做日志缓冲先写入文件系统缓存。为了确保充足哦日志写入磁盘,必须进行一次fsync操作。
由此可见,数据库性能受fsync操作磁盘性能的瓶颈的影响。
可以通过手工设置,让数据库等待一个时间周期在执行fsync操作。将尽可能多的fsync磁盘操作合并在一起操作,这样可以明显提升性能。但是这违反了持久性原则,当发生数据库宕机时,会丢失最后一段时间的事务。
参数innodb_flush_log_at_trx_commit就是来控制充足哦日志拴心到磁盘的策略的。
默认值1,表示事务提交时必须调用一次fsync。
0,表示事务提交时不进行写入重做日志操作。这个操作将仅在master thread中进行,在master thread中每1秒会进行一次重做日志文件的fsync操作。
2,表示事务提交时,将重做日志写入文件系统的缓存中,不进行fsync操作。当数据库发生宕机时,不会导致事务的丢失。但操作系统宕机时,会丢失未从文件系统缓存刷新到重做日志文件的那部分事务。
在较大数据操作情况下,设置未0时性能最好,2次之,1最差。0和1之间的性能可能相差10倍。
在InnoDB存储引擎中,重做日志都是以512自己进行存储的。重做日志缓冲和重做日志文件都是这样。称之为重做日志块,每块大小512字节。
重做日志块可以存储492字节内容。另外的空间头信息占用12字节,尾信息占用8自己。
重做日志允许有多个重做日志文件,我们称为重做日志组。组中的每一个日志文件大小时享用的。InnoDB存储引擎1.2版本以前,重做日志文件的总大小瑶小雨4GB,从1.2版以后限制提高为512G。
重做日志缓冲刷新到重做日志文件,由以下3个规则控制:
1.事务提交时
2.log buffer中有一半的内存空间已经被使用时
3.log checkpoint时
重做日志组中第一个日志文件,其前2K部分不保存重做日志信息。它分为4块,分别保存log file header,checkpoint1,空,checkpoint2.
其余的重做日志文件则是保留文件签2K空间不用。
说到checkpoint,就不得不提到LSN(Log Sequence Number),日志序列号。
其占用8字节,单调递增。其表示:
1.重做日志写入的总量
2.checkpoint的位置
3.页的版本
当MySQL重启的时候,无论是否是正常关闭,都会尝试进行恢复操作。重做日志就是在这个阶段发挥作用。因为是物理日志,所以速度要比二进制日志快很多。checkpoint表示已经刷新到磁盘页上的LSN,因此恢复过程仅需从checkpoint开始的部分开始。