概述
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 找对应的事务。
