MySQL - 日志 - redo log

概述

redo log是InnoDB引擎特有的物理日志。redo log记录了数据被修改后的值，确保事务的持久性。
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

redo log 物理文件

InnoDB 的 redo log 是固定大小的，
比如可以配置为一组 4 个文件: 0 ~ 3，每个文件的大小是 1GB。
从头开始写到尾后会开始擦除头部进行循环写。如图：

111.png

可以通过配置参数

  innodb_log_files_in_group 日志文件数量
  innodb_log_file_size 文件大小

redo log 写入包括两部分：

内存日志缓冲(redo log buffer)
基于内存，性能快，但易丢失。
重做日志文件(redo log file)
基于磁盘，将文件写入磁盘进行持久化(由于redo log file是循环擦除写，会导致历史记录丢失，这里涉及到二阶段提交到binlog进行持久化)。

redo log写入机制

事务执行时是先写入redo log buffer （必须）
write 写到文件系统的 page cache (可选)
fsync 持久化到磁盘 (可选)

可以通过参数对redolog写入策略进行配置：

# 配置文件：mysql.ini
innodb_flush_log_at_trx_commit = 1

设为0时，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;(不主动刷到磁盘)
设为1时，表示每次事务提交时都将 redo log 直接持久化到磁盘；
设为2时，表示每次事务提交都只是吧redolog写到page cache
注：InnoDB 后台线程每1 秒就会把 redo log buffer 中的日志调用 write 写到文件系统的 page cache然后调用 fsync 持久化到磁盘。一个没有提交的事务的 redo log，也是可能已经持久化到磁盘的。

另外两种场景也会触发未提交事务的redo log 写入磁盘:

redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半时。
注：由于事务并没有提交，所以写盘动作只是 write，未调用 fsync，也就是只留在了文件系统的 page cache。
innodb_flush_log_at_trx_commit = 1 情况下
多事务并行，当有事务先提交时，其他事务还停留在redo log buffer 也会提前触发写磁盘

二阶段提交

222.png

阶段一：写入redo log完成时，阶段处于prepare
阶段二：binlog 也写入成功，阶段才处于commit

崩溃恢复时的判断规则:

如果 redo log 里面的事务是完整的，也就是已经有了 commit 标识，则直接提交；
如果 redo log 里面的事务只有完整的 prepare，则判断对应的事务 binlog 是否存在并完整：
是提交事务，否回滚事务。

redo log 和 binlog 通过共同数据字段：XID关联

崩溃恢复时会按顺序扫描 redo log：

如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。