MySQL事务日志—redo日志介绍

MySQL事务日志—redo日志

事务有4种特性： 原子性、一致性、隔离性和持久性。

那么事务的四种特性到底是基于什么机制实现?

• 事务的原子性、一致性由事务的 undo 日志
• 事务的隔离性由锁机制和MVCC实现。
• 事务的持久性由redo 日志来保证。

两类日志概述：

• REDO LOG 称为重做日志，用于保存已提交事务的页修改操作， 保证事务的持久性。
• UNDO LOG 称为回滚日志， 回滚行记录到某个特定版本， 用来保证事务的原子性、一致性。

redo日志作用

背景：在真正访问页面之前，需要把在磁盘上的页缓存到内存中的 Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘(checkPoint机制 ) ，通过缓冲池来优化CPU和磁盘之间的鸿沟， 这样就可以保证整体的性能不会下降太快。

问题：事务提交并不会触发check point机制马上进行持久化，所以有可能存在事务内容丢失的情况。

redo日志就是保证事务提交后的持久化的一种机制。如果发生宕机，只需要保证数据页的修改记录已经保存到了在redo log中，之后重启就就可以通过redo log去重新刷盘，保证了持久化。

为什么不是直接刷盘，而是把内存数据的修改记录到redo日志里？redo日志不也是磁盘中的吗？

1. 数据修改量与刷盘的数据量的差距太大，因为mysql是以页为单位进行IO，而修改的数据量可能只有几个字节。
2. 直接刷盘效率太低，因为SQL修改的磁盘页不一定连续，所以说是随机IO。

使用redo日志的优点？

1. 降低了完整刷盘的频率，每次只记录页面修改的内容即可
2. redo log是顺序写入磁盘的，属于顺序IO，效率高

redo log什么时候产生？

实时产生，每执行一个SQL语句对应的数据修改都会记录在redo log中，而不是事务提交才记录。

redo日志工作原理

redo log的组成

Redo log可以简单分为以下两个部分：

• 重做日志的缓冲 ( red o log buffer) , 保存在内存中, 是易失的。

• 

• 重做日志文件 ( redo log file) , 保存在硬盘中, 是持久的。如var/lib/mysql目录下的ib_logfile0和 ib _logfile1 文件即为REDO日志。

redo log工作流程

InnoDB的更新操作采用的是 Write Ahead Log(预先日志持久化)策略, 即先写日志, 再写入磁盘。

mysql事务对数据进行修改，大致过程：

1. 开始一个事务
2. 执行SQL语句，先将原始数据从磁盘中读入内存的buffer pool中来
3. 记录数据旧值到undo log以便于回滚，然后再对内存中的buffer pool数据进行修改
4. 将内存页的修改情况记录到redo log buffer（内存中）
5. 如果事务中途失败，则通过undo log回滚
6. commit事务，根据刷盘策略的配置决定采取什么行为，默认：把redo buffer数据直接追加到redo磁盘文件中
7. 按照一定频率执行真正的刷盘（check point机制）
8. 如果事务成功commit但没有成功刷盘的时候（步骤5-6之间），发生宕机，则重启后会根据redo日志中的记录再执行刷盘

redo日志刷盘策略

redo log刷盘策略是指将redo buffer同步到redo log磁盘文件中的过程

注意：redo log buffer刷盘到 redo log file的过程并不是真正的刷到磁盘中去, 只是刷入到文件系统缓征 ( page cache) 中去 ， 真正的写入会交给系统自己来决定。那么对于InnoDB来说就存在一个问题， 如果交给系统来同步， 同样如果系统宕机，那么数据也丢失了 (虽然整个系统宕机的概率还是比较小的) 。

针对这种情况, InnoDB给出 innodb _ flush _ log _ at _ trx _ commit参数, 该参数控制 commit提交事务时, 如何将 redo log buffer中的日志刷新到 red o log file中。它支持三种策略:

• 设置为0： 表示每次事务提交时不进行刷盘操作。(系统默认 master thread每隔1s进行一次重做日志的同步)
• 设置为1 ： 表示每次事务提交时都将进行同步， 刷盘操作 (默认值)
• 设置为2: 表示每次事务提交时都只把 red o log buffer 内容写入 page cache, 不进行同步。由 os自己决定什么时候同步到磁盘文件。（其实也是交给master thread处理）

拓展：master thread是InnoDB存储引擎的后台线程, 每隔1 秒, 就会把 redo log buffer 中的内容写到文件系统缓存( page cache) , 然后调用刷盘操作。三种刷盘策略都会收到master thread的影响。

策略一：事务提交，立马同步到redo log文件

优点：安全性很高，只要事务提交了，数据就是安全的

缺点：速度慢

数据丢失场景：事务没有完成提交（会回滚）

策略二：事务提交，只保存到文件系统的page cache

优点：速度快，安全性也相对较高，因为只要把修改记录保存到page cache中了，即使MySQL崩溃了，数据也还是能够保证持久化，除非整个系统宕机了（概率小）

缺点：有概率产生事务数据丢失的情况，丢失1s的数据（等待master thread同步的1s的过程中宕机了）

数据丢失场景：事务提交后的1s内，操作系统挂了

策略三：事务提交，什么也不干

优点：速度快

缺点：安全性差，1s内发生MySQL奔溃或者OS宕机，都会丢失事务的修改数据

数据丢失场景：事务提交后的1s内，MySQL或者操作系统挂了

总结

redo buffer是实时变化的，而刷盘不是实时进行的，根据同步时机，可分为如下三种：

• 事务commit时，将redo buffer同步到操作系统的文件缓存cache中，然后马上将文件缓存cache同步写入到redo log文件中（默认，做两步）
• 事务commit时，只将redo buffer同步到操作系统的文件缓存cache中，具体什么时候同步到redo log文件中，取决于后台子线程（做一步，另一步交给后台线程）
• 事务commit时，什么也不做，什么时候同步完全取决于后台子线程（什么都不做，都交给后台线程）

三种策略的安全性由高到低，速度由慢到快，但出于安全考虑，最好还是选择默认的。