MySQL中的重做日志（redo log），回滚日志（undo log），以及二进制日志（binlog）的简单总结

MySQL中有六种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。
其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。

这里简单总结一下这三者具有一定相关性的日志。

重做日志（redo log）

• 作用：
  防止在发生故障的时间点，尚有脏页
  未写入磁盘（事务提交之后，数据写入磁盘之前宕机），在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
• 内容：
  物理格式的日志，记录的是物理数据页面的修改信息，其redo log是顺序写入redo log file的物理文件中去的。
• 生成时机：
  事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。
• 释放时机：
  当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

缓冲区 Innodb_log_buffer

重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为16Mb，Innodb 存储引擎先将重做日志写入 Innodb_log_buffer中，然后会通过以下三种方式将 Innodb 日志缓冲区的日志刷新到磁盘：

1. Master Thread 每秒一次执行刷新 Innodb_log_buffer 到重做日志文件
2. 每个事务提交时会刷新。
3. 当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件。

因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。

回滚日志（undo log）

• 作用：
  保存了事务发生之前数据的一个版本，可以用于回滚。事务回滚时，会根据 undo log 将数据从逻辑上恢复至事务之前的状态。
• 内容：
  逻辑格式的日志，在执行undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。
• 生成时机：
  事务开始之前，将当前事务版本生成 undo log，undo 也会产生 redo 来保证 undo log 的可靠性。每一次写操作都会生成 undo log，比如 update 操作，会生成一条更新前的记录信息，比如主键ID，需要更新的字段以及字段对应的旧值。对于 DELETE 操作，在 delete mark 操作时，会获取该条记录最近一次的 undo log 记录，生成的新的 undo log 记录了旧记录的 trx_id（事务编号） 和 old roll_pointer（上一个 undo log 的位置） ，这样回滚时，就可以直接找到删除之前的 undo log 进行回滚操作。
• 释放时机：
  当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否有其他事务在使用 undo 段中表的上一个事务之前的版本信息，决定是否可以清理 undo log 的日志空间。

二进制日志（binlog）

• 作用：
  1. 用于复制，在主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。
  2. 用于数据库的基于时间点的还原。
• 内容：
  逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。
• 生成时机：
  事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
  这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候才刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。
• 释放时机：
  binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

MySQL通过两阶段提交过程来完成事务的一致性的，也即 redo log 和 binlog 的一致性的，理论上是先写 redo log，再写 binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。