MySQL事务日志—redo日志
事务有4种特性： 原子性、一致性、隔离性和持久性。
那么事务的四种特性到底是基于什么机制实现?
- 事务的原子性、一致性由事务的 undo 日志
- 事务的隔离性由锁机制和MVCC实现。
- 事务的持久性由redo 日志来保证。
两类日志概述：
- REDO LOG 称为重做日志，用于保存已提交事务的页修改操作， 保证事务的持久性。
- UNDO LOG 称为回滚日志， 回滚行记录到某个特定版本， 用来保证事务的原子性、一致性。
redo日志作用
背景：在真正访问页面之前，需要把在磁盘上的页缓存到内存中的 Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘(checkPoint机制 ) ，通过缓冲池来优化CPU和磁盘之间的鸿沟， 这样就可以保证整体的性能不会下降太快。
问题：事务提交并不会触发check point机制马上进行持久化，所以有可能存在事务内容丢失的情况。
redo日志就是保证事务提交后的持久化的一种机制。如果发生宕机，只需要保证数据页的修改记录已经保存到了在redo log中，之后重启就就可以通过redo log去重新刷盘，保证了持久化。
为什么不是直接刷盘，而是把内存数据的修改记录到redo日志里？redo日志不也是磁盘中的吗？
- 数据修改量与刷盘的数据量的差距太大，因为mysql是以页为单位进行IO，而修改的数据量可能只有几个字节。
- 直接刷盘效率太低，因为SQL修改的磁盘页不一定连续，所以说是随机IO。
使用redo日志的优点？
- 降低了完整刷盘的频率，每次只记录页面修改的内容即可
- 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事务对数据进行修改，大致过程：
- 开始一个事务
- 执行SQL语句，先将原始数据从磁盘中读入内存的buffer pool中来
- 记录数据旧值到undo log以便于回滚，然后再对内存中的buffer pool数据进行修改
- 将内存页的修改情况记录到redo log buffer（内存中）
- 如果事务中途失败，则通过undo log回滚
- commit事务，根据刷盘策略的配置决定采取什么行为，默认：把redo buffer数据直接追加到redo磁盘文件中
- 按照一定频率执行真正的刷盘（check point机制）
- 如果事务成功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时，什么也不做，什么时候同步完全取决于后台子线程（什么都不做，都交给后台线程）
三种策略的安全性由高到低，速度由慢到快，但出于安全考虑，最好还是选择默认的。
