MySQL日志系统：redo log与binlog

共计 1479 个字符，预计需要花费 4 分钟才能阅读完成。

日志系统主要有 redo log(重做日志)和 binlog(归档日志)。redo log 是 InnoDB 存储引擎层的日志，binlog 是 MySQL Server 层记录的日志，两者都是记录了某些操作的日志 (不是所有) 自然有些重复（但两者记录的格式不同）。

图来自极客时间的 mysql 实践, 该图是描述的是 MySQL 的逻辑架构。

redo log 日志模块

redo log 是 InnoDB 存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log 文件就能派上用场，如数据库掉电，InnoDB 存储引擎会使用 redo log 恢复到掉电前的时刻，以此来保证数据的完整性。

在一条更新语句进行执行的时候，InnoDB 引擎会把更新记录写到 redo log 日志中，然后更新内存，此时算是语句执行完了，然后在空闲的时候或者是按照设定的更新策略将 redo log 中的内容更新到磁盘中，这里涉及到 WAL 即Write Ahead logging技术，他的关键点是先写日志，再写磁盘。

有了 redo log 日志，那么在数据库进行异常重启的时候，可以根据 redo log 日志进行恢复，也就达到了crash-safe。

redo log 日志的大小是固定的，即记录满了以后就从头循环写。

图片来自极客时间，该图展示了一组 4 个文件的 redo log 日志，checkpoint 之前表示擦除完了的，即可以进行写的，擦除之前会更新到磁盘中，write pos 是指写的位置，当 write pos 和 checkpoint 相遇的时候表明 redo log 已经满了，这个时候数据库停止进行数据库更新语句的执行，转而进行 redo log 日志同步到磁盘中。

binlog 日志模块

binlog 是属于 MySQL Server 层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的是这个语句的原始逻辑，依靠 binlog 是没有 crash-safe 能力的

redo log 和 binlog 区别

• redo log 是属于 innoDB 层面，binlog 属于 MySQL Server 层面的，这样在数据库用别的存储引擎时可以达到一致性的要求。
• redo log 是物理日志，记录该数据页更新的内容；binlog 是逻辑日志，记录的是这个更新语句的原始逻辑
• redo log 是循环写，日志空间大小固定；binlog 是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。
• binlog 可以作为恢复数据使用，主从复制搭建，redo log 作为异常宕机或者介质故障后的数据恢复使用。

一条更新语句执行的顺序

update T set c=c+1 where ID=2;

• 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
• 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
• 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
• 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
• 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。

图片来自极客时间.