浅谈mysql日志系统

日志类型

• redolog

• undolog

• binlog

• errorlog

• slow query log

• general log

• relaylog

谈谈redolog 、 undolog 和 binlog的异同

1. 实现层级

binlog是mysql服务层实现的

redolog和undolog是引擎层实现的, 只存在于innodb中，myisam引擎并没有实现, 统称为事务日志

2. 用途

• redo log
  确保事务的持久性

  如果发生故障时（如: 系统宕机, 电源异常等），尚有数据未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达保证事务的持久性。

• undo log

  • 用于回滚
  • MVCC

  首先明确undo log绝对不是redo log的逆过程。它可以保存事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制（MVCC）下的读。

• binlog

  • 复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的
  • 数据恢复：通过mysqlbinlog工具恢复数据
  • 增量备份

3.存储内容、格式

• redo log
  物理日志

  记录的是物理数据页面的修改的信息（数据库中每个页的修改），面向的是表空间、数据文件、数据页、偏移量等。

• undo log
  逻辑日志
  在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，与redo log不同。

• binlog
  逻辑日志

  记录的是对数据存在变更的sql语句。

  binlog只会保存对数据存在更改的记录，像select/show这类查询类的语句是不记录的。

4. 生命周期

• redolog
  事务开始之后，就开始产生 redo log 日志了，在发出事务提交指令时，先保证缓存中的redo log写入完毕，才执行提交动作。
  当对应事务的数据写入完成（持久化完成）之后，redo log的使命也就完成了，日志占用的空间就可以重用（redo log的日志文件是循环写入的）。

• undolog
  事务开始之前，将当前事务版本生成 undo log，undo log 也会产生 redo log 来保证 undo log 的可靠性。
  当事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表，
  由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。

• binlog
  事务提交的时候，一次性将事务中的 所有sql 语句按照一定的格式记录到 binlog 中，这里与 redo log 很明显的差异就是 redo log 并不一定是在事务提交的时候才刷新到磁盘，而是在事务开始之后就开始逐步写入磁盘。binlog 的默认保存时间是由参数 expire_logs_days 配置的，对于非活动的日志文件，在生成时间超过 expire_logs_days 配置的天数之后，会被自动删除。

两阶段提交

redolog和binlog都写入了之后再提交数据，确保日志数据都正常了才写入磁盘。
redolog 保证的是数据库的 crash-safe 能力。采用的策略就是常说的“两阶段提交”。

一条update的SQL语句是按照这样的流程来执行的：

将数据页加载到内存 → 修改数据 → 更新数据 → 写redolog（状态为prepare） → 写binlog → 提交事务（数据写入成功后将redo log状态改为commit）

其他相关文档建议

腾讯工程师带你深入解析 MySQL binlog
详细分析MySQL事务日志(redo log和undo log)