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 对应的记录也就没用了,这时候需要擦除这些旧记录,以腾出空间记录新的更新操作。

你可能感兴趣的:(javamysql)