MYSQL 故障恢复 —— 重做日志 Redo Log

一、Redo Log作用

主要用于故障恢复。
在MYSQL崩溃恢复时，纠正不完整事务写入的数据，保证已提交事务ACID，同时能够提高数据库性能。

---

二、Redo Log所属

innodb引擎存储引擎层

---

三、Redo Log Buffer

Redo Log Buffer 占用一块连续的内存空间（在buffer pool中），默认大小为 16MB。

redo log block
redo log 是按块，一块块地写入到磁盘中去的。
同一个事务产生的 redo log 会被标记为一个 redo log group，持续写入到 redo log block 中。

---

四、WAL（Write-Ahead Logging）先行日志

MySQL的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时机再写到磁盘上

当有一条记录需要更新的时候：

1. InnoDB 引擎就会先更新Buffer Pool数据页，同时标记为脏页；
2. 将本次对这个页的修改以 Redo Log 的形式记录下来（持久化到磁盘）；
3. InnoDB会在适当的时候，用后台线程将缓存在Buffer Pool的脏页刷新到磁盘里

---

五、Redo Log刷盘策略

写Redo Log的时候，默认会先写入Redo Log Buffer，再按照不同的持久化策略写入到磁盘Redo Log File中。
如果 redo log 提交完成了，事务就不能回滚了。

---

六、持久化

持久化到磁盘主要有以下几个时机：

• MySQL 正常关闭时；
• 当Redo Log Buffer内存空间使用过半时，会触发落盘；
• InnoDB 的后台线程每隔 1 秒，将 redo log buffer 持久化到磁盘。
• 每次事务提交时都将缓存在 Redo Log Buffer 里的 redo log 直接持久化到磁盘（由 innodb_flush_log_at_trx_commit 参数控制）。

三种写入redo log file的策略

innodb_flush_log_at_trx_commit	作用	缺点
0 （延迟写）	事务提交时，先写入redo log buffer，然后每秒写入redo log文件，并持久化到磁盘	当系统崩溃时会丢失1秒的数据
1 （实时写，实时刷）	事务提交时，直接写入redo log文件，并持久化到磁盘
2 （实时写，延迟刷）	事务提交时，直接写入Page Cache，每秒将Page Cache数据持久化到磁盘

---

七、循环写

InnoDB 存储引擎有一个 redo log group，由两个 redo log 文件组成。两个文件的大小固定且一致。

redo log 是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

如果 Buffer Pool 的脏页刷新到了磁盘中，那么 redo log 对应的记录也就没用了，这时候需要擦除这些旧记录，以腾出空间记录新的更新操作。