MYSQL三大日志-binlog、redo log、undo log
前言
我们都清楚日志是mysql的一个重要组成部分，记录着数据库运行期间各种状态信息。而Mysql日志又分为错误日志、查询日志、慢查询日志、二进制日志(binlog)和事务日志(redo log、undo log)。其中在我们开发中聊的比较多的就是二进制日志(binlog)和事务日志(redo log、undo log)。其实慢查询日志也是我们开发中比较常见的日志，常用于sql优化。本文主要介绍binlog、redo log、undo log三种日志
专业名词知识
首先，我们先来了解一下mysql中的专业名词，看到一篇InfoQ的文章介绍的还不错，那么直接引入文章的截图：
这些名词的话在后面的文章中可能会出现，这里先做一个了解。
BinLog(二进制日志)
二进制日志：binary log。简称binLog。记录了对Mysql数据库执行更改的所有操作，但是不包括SELECT 和 SHOW这类操作。以二进制的形式保存在磁盘中。是属于Mysql Server层记录，任何存储引擎的 mysql 数据库都会记录binlog日志。并且binlog 还是 mysql 的逻辑日志
逻辑日志：可以简单理解为记录的就是sql语句
物理日志：mysql 数据最终是保存在数据页的，物理日志记录的就是数据页变更
binlog 是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到max_binlog_size后，会生成新的二进制日志文件来保存。从Mysql5.0后默认值1073741824(1G)
binlog使用场景
binlog 的主要使用场景有两个，分别是 主从复制 和 数据恢复
主从复制：在 Master 端开启 binlog，然后将 binlog 推送到各个 Slave 从端，Slave 端重放 binlog 从而达到主从数据一致
数据恢复：通过使用 mysqlbinlog 工具来恢复数据
binlog 记录过程及刷盘时机
binlog 大致记录过程是将所有未提交(uncommitted)的二进制日志写入到 binlog buffer中，等该事务提交(committed)时，然后通过刷盘时机，控制刷入 OS Buffer，控制 fsync() 进行写入 Binlog File 日记文件磁盘的过程。
对于 binlog, MYSQL 是通过参数 sync_binlog 参数来控制刷盘时机，取值范围是 0-N:
- 0: 不去强制要求，由系统自行判断何时写入磁盘
- 1: 每次事务提交(committed)的时候都要将 binlog 写入磁盘
- N: 每提交 N 个事务，才会将 binlog 写入磁盘
可以看出当 sync_binlog = 1时，数据是最安全的。这也是MySQL 5.7.7之后的版本的默认值。但是这样的话可以会牺牲一定的性能来保证数据的一致性。
binlog 日志格式
binlog 日志有三种格式，分别为 STATMENT、ROW 和 MIXED
在MYSQL 5.7.7 之前，默认的格式是 STATMENT，MySQL 5.7.7 之后，默认值是 ROW， 日志格式可以通过binlog-format 指定
- STATMENT：基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog 中
- 优点：不需要记录每一行的变化，减少了binlog 日志量，节约了 IO，从而提高了性能
- 缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()等
- ROW：基于行的复制(row-based replication, RBR)，不记录每条sql语句的上下文，记录哪条数据被修改了
- 优点：能够解决特定情况下的存储过程、或function，或trigger的调用和触发无法被正确复制的问题
- 缺点：会产生大量的日志，尤其是'alter table'的时候会让日志暴涨
- MIXED：基于STATMENT 和 ROW 两种模式的混合复制(mixed-based replication, MBR)，默认采用 STATMENT 格式进行二进制日志文件的记录，但是在一些情况下会使用ROW格式，可能的情况有：
- 1): 表的存储引擎为NDB，这时对表的 DML 操作都会以 ROW 格式记录
- 2): 使用了 UUID()、USER()、 CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数
- 3): 使用了INSERT DELAY 语句
- 4): 使用了用户定义函数 (UDF)
- 5): 使用了临时表(temporary table)
redo log(重做日志)
我们都知道，事务有一个特性叫做 持久性。也就是事务提交成功，那么对数据库做的修改就被永久保存下来，不可能因为任何原因再回到原来的状态。
那么，mysql是如何保证一致性的呢？
最简单的办法就是每次事务提交成功，将该事务涉及修改的数据页全部刷新到磁盘。但是这么做会有严重的性能问题，主要体现在下面两个方面：
- 因为 InnoDB 是以 页 为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候如果将完整的数据页全部刷新到磁盘的话，太浪费资源了
- 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差
因此 mysql 设计了 redo log， 具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
Redo Log概念
Redo log 是重做日志，属于 InnoDB储存引擎的日志。是物理日志，日志记录的内容是数据页的更改，这个页"做了什么改动"。如：add xx记录 to Page1，向数据页Page1增加一个记录。
redo log 包括两部分：一个是内存中的日志缓冲(redo log buffer)，其是易失的。二是重做日志文件(redo log file)，其是持久的。
Redo Log作用
- 前滚操作：具备 crash-safe 能力，提供断电重启时解决事务丢失数据问题
- 提高性能：mysql 每执行一条 DML 语句，先将记录写入 redo log buffer。当等到有空闲线程、内存不足、Redo Log满了时刷脏。写Redo log 是顺序写入，刷脏是随机写，节省的是随机写磁盘的 IO 消耗 (转成顺序写)，所以性能得到提升。此技术成为WAL技术：Write-Ahead Logging，它的关键点就是先写日志磁盘，再写数据磁盘。具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做
Redo log两阶段提交
mysql为了保证 Binlog 和 Redo log 数据的一致性，采用了两阶段提交
可以看到将 redo log 的写入拆成了两个步骤：prepare 和 commit两个阶段
为什么需要采用"两阶段提交"呢？
这里假设不采用"两阶段提交"的话，写入完 redo log，接着写binlog时，这时候数据库崩溃，这时候 binlog 里面就没有记录这个语句。但是 redo log里面会保存这条 c的值是1的记录，数据库崩溃我们也是可以通过redo log的日志将数据恢复过来。如果我们需要备份日志的时候，存起来的 binlog 没有这条语句，需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。所以我们需要保证redo log 跟 binlog 数据一致性
Redo log 容灾恢复过程
- 判断 redo log 是否完整，如果判断是完整(commit)的，直接用 Redo log恢复
- 如果 redo log 只是预提交 prepare 但不是 commit 状态，这个时候会去判断 binlog 是否完整，如果完整就提交 Redo log，用 Redo log 恢复，不完整就回滚事务，丢弃数据。
只有在 redo log 状态为 prepare 时，才会去检查 binlog 是否存在，否则只校验 redo log 是否是 commit 就可以啦。怎么检查 binlog：一个完整事务 binlog 结尾有固定的格式。
Redo log 刷盘时机
在计算机操作系统中，用户空间(User Space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间( kernel space )缓冲区( OS buffer)
因此，redo log每次先写入 redo log buffer中，然后通过刷盘时机，将 redo log buffer 的数据写入 redo log file，写入 redo log file 实际上是先写入 OS Buffer，然后再通过系统调用 fsync() 将其刷到 redo log file中，大致过程：
mysql 通过参数 innodb_flush_log_at_trx_commit 来控制刷盘时机，取值是0、1和2三种值。
- 0(延迟写): 事务提交时并不会立即将 redo log buffer 中日志写入到 os buffer中，而是每秒写入 os buffer 并调用 fsync() 写入到 redo log file 中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据
- 1(实时写，实时刷)：事务每次提交都会将 redo log buffer 中的日志写入 os buffer 并调用 fsync() 刷到 redo log file 中。这种方式即使系统崩溃也不会丢失任何数据，是最安全的，同时也是默认值
- 2(实时写，延迟刷)：每次提交都仅写入到 os buffer，然后是每秒调用 fsync() 将 os buffer 中的日志写入到 redo log file
Redo log 存储方式
前面说过，redo log 实际上记录数据页的变更，而这种变更记录是没必要一直保存，因此 redo log 实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。如下图：
上图是日志磁盘的 Redo log 环形设计图（从头开始写，写到结束又从头开始写~循环）。write pos 和 check point 是两个指针，write pos 表示 redo log 当前记录的 LSN(日志逻辑序列号(占用8字节))位置，check point 表示数据页更改记录刷盘后对应 redo log 所处的 LSN(日志逻辑序列号)位置。
write pos 到 check point 之间的部分(图中绿色的部分)，用于记录新的记录; check point 到 write pos 之间是 redo log 待落盘的数据页更改记录。每次写入，write pos 指针会顺时针推进，当 write pos追上check point 时，会先推动 check point 向前移动，空出位置再记录新的日志
Redo log 容灾恢复过程
启动 innodb 的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为 redo log 记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如 binlog )要快很多。
重启 innodb 时，首先会检查磁盘中数据页的 LSN，如果数据页的 LSN 小于 redo log 日志中的 LSN，则会从 checkpoint 开始恢复。
还有一种情况，在宕机前正处于 checkpoint 的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的 LSN 大于 redo log 日志中的 LSN，这时超出日志进度的部分将不会被重做，因为这本身就表示已经做过的事情，无需再重做
提问1: 为啥 Binlog 没有 crash-safe 功能？
redo log 和 binlog 有一个很大的区别就是，一个是循环写，一个是追加写。也就是说 redo log 只会记录未刷盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。binlog 是追加日志，保存的是全量日志。
当数据库 crash 后，想要恢复未刷盘但已经写入 redo log 和 binlog 的数据，binlog 是无法恢复的。虽然 binlog 拥有全量的日志，但没有一个标志让 innodb 判断哪些数据已经刷盘，哪些数据还没有
举个例子, binlog 记录了两条日志：
1. 给 ID = 2 这一行的 c 字段加1
2. 给 ID = 2 这一行的 c 字段加2
在记录1刷盘后，记录2未刷盘时，数据库 crash。重启后，只通过 binlog 数据库无法判断这两条记录哪条已经写入磁盘，哪条没有写入磁盘，不管是两条都恢复至内存，还是都不恢复，对 ID=2 这行数据来说，都不对
但 redo log 不一样，只要刷入磁盘的数据，都会从 redo log 中抹掉，数据库重启后，直接把 redo log 中的数据都恢复至内存就可以了。这就是为什么 redo log 具有 crash-safe 的能力，而 binlog 不具备
提问2: 保证 crash-safe 为啥要用两个日记，不能用一个日记吗（Redo log 或 Binglog）?
针对问题1我们知道只有 binlog 日志，没有 redo log 是不能做到故障恢复的。那么针对只有 redo log日志，没有 binlog 日志，这也是不行的，因为 redo log 是 innodb 持有的，且日志上的记录落盘后会被抹掉。因此需要 binlog 和 redo log 两者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。
undo log(回滚日志)
我们都知道事务四大特性中有一个是原子性，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况
实际上，原子性 底层就是通过 undo log 实现的。undo log 主要记录了数据的逻辑变化，比如一条INSERT 语句，对应着有一条的DELETE的undo log，对于每个UPDATE 语句，对应一条相反的 UPDATE 的 undo log，这样在发生错误时，就能回滚到事务之前的数据状态
undo log 跟 redo log 是属于innodb 引擎的日志
undo log 作用
- 回滚数据：当数据发生异常错误时，根据执行 undo log 就可以回滚到事务之前的数据状态，保证原子性，要么全部成功，要么全部失败
- MVCC 一致性视图：通过 undo log 找到对应的数据版本号，是保证 MVCC 视图的一致性的必要条件
undo log 记录过程及刷盘时机
undo log 的记录过程的话跟 redo log 过程差不多，都是先记录到 Log Buffer 中，然后通过刷盘时机将 buffer 中的日志 刷新到 undo log file 中。但是对于 undo log 没找到对应的刷盘参数设计
总结
前面主要介绍了 binlog、redo log、undo log三种日志。binlog是属于mysql Server层的，属于整个mysql的，而redo log、undo log是属于innodb存储引擎独有的，redo log、undo log是事务日志，binlog是二进制日志负责记录对mysql数据库有修改的sql操作。其中还有难懂的点就是redo log进行容灾恢复的过程LSN(日志逻辑序列号)的比较，里面并不简简单单就是我列举的那样，因为篇幅有限，这里就没做具体的详解了，只列举了一个大概的比较过程。
