九、日志模块

总结

• bin log：记录数据库表结构和表数据的变更。
• undo log：记录数据的反向操作，如 insert 操作就记一条 delete 日志。
• redo log：记录事务（所以 InnoDB 特有）对数据页的修改。

1. bin log

bin log 记录了数据库表结构和表数据变更，比如 update/delete/insert/truncate/create。它不会记录 select（因为这没有对表没有进行变更）。

主要有两个作用： 复制和恢复数据

• MySQL 在公司使用的时候往往都是一主多从结构的，从服务器需要与主服务器的数据保持一致，这就是通过 bin log 来实现的
• 数据库的数据被干掉了，我们可以通过 bin log 来对数据进行恢复。

因为 bin log 记录了数据库表的变更，所以我们可以用 bin log 进行复制（主从复制）和恢复数据。

2. undo log

数据库事务四大特性中有一个是 原子性 ，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

实际上， 原子性 底层就是通过 undo log 实现的。undo log主要 **记录了数据的逻辑变化，比如一条 INSERT 语句，对应一条DELETE 的 undo log **，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。

同时， undo log 也是 MVCC(多版本并发控制)实现的关键。

3. redo log

事务的四大特性里面有一个是 持久性 ，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态 。

因此 mysql 设计了 redo log ， 具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了（相对而言文件更小并且是顺序 IO）。

redo log 是 MySQL 的 InnoDB 引擎所产生的。bin log 无论 MySQL 用什么引擎，都会有的。redo log 事务开始的时候，就开始记录每次的变更信息，而 bin log 是在事务提交的时候才记录。

• 如果写 redo log 失败了，那我们就认为这次事务有问题，回滚，不再写 bin log。
• 如果写 redo log 成功了，写 bin log。
  • 写 bin log 写一半了，但失败了怎么办？我们还是会对这次的事务回滚，将无效的 bin log 给删除（因为 bin log 会影响从库的数据，所以需要做删除操作）。
  • 如果写 redo log 和 bin log 都成功了，那这次算是事务才会真正成功。

MySQL 如何保证 redo log 和 bin log 的数据是一致的？

MySQL 通过两阶段提交来保证 redo log 和 bin log 的数据是一致的。

过程：

• 阶段1：InnoDB redo log 写盘，InnoDB 事务进入 prepare 状态
• 阶段2：bin log 写盘，InooDB 事务进入 commit 状态

每个事务 bin log 的末尾，会记录一个 XID event，标志着事务是否提交成功：

• XID event 存在：事务成功，提交
• XID event 不存在：事务失败，回滚

也就是说，恢复过程中，bin log 最后一个 XID event 之后的内容都应该被 purge（清除）。