redo log 和 binlog 的一些总结

1 redo log 和 binlog 的区别

  1. redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。
  2. redo log 是物理日志,记录的是“在某个数据页上做了什么修改,实现 crash-safe即使数据库发生异常重启,之前提交的记录都不会丢失。而 binlog 是逻辑日志,记录的是写入性操作(不包括查询)信息,比如“给 ID=5 这一行的 c 字段加 1 ”,保证数据的一致性。
  3. redo log 是循环写的,空间固定会用完;binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
  4.  binlog 仅在事务提交时记录,并且对于每一个事务,仅包含对应事务的一个日志。而对于 redo log,由于其记录的是物理操作日志,因此每个事务对应多个日志条目。

 

redo log 和 binlog 的相同点

 redo log 和 binlog 落盘的步骤是差不多的,都分为三部分。

  1. 将日志写入 log buffer 和 binlog cache。
  2. 将上述的内容写入操作系统的 file system page cache。
  3. 由操作系统将文件缓存中的数据写入到磁盘中。

 

3 redo log 的两阶段提交

对数据进行修改后,需要写入 redo log 和 binlog,那么这势必存在一个先后顺序,假设执行过程中写完 redo log 日志后,binlog 日志写期间发生了异常,会发生什么?

由于 binlog 没写完就异常,这时候 binlog 里面没有对应的修改记录。从机用 binlog 日志更新数据时,就会少这次更新,而主机用 redo log 日志恢复,会导致最终数据不一致的情况。

为了解决两份日志之间的逻辑一致问题,InnoDB 使用两阶段提交方案,将 redo log 的写入拆成 preparecommit 两阶段。

在数据库发生崩溃重启后,它将会去检查 redo log:

  1. 如果 redo log 有 commit 标识则直接提交事务。
  2. 如果 redo log 没有 commit 标识且不存在对应的完整 binlog,则回滚事务。redo log 和 binlog 有一个共同的数据字段,叫XID。崩溃恢复的时候,redo log 会拿着 XID 去 binlog 找对应的事务。
  3. 如果 redo log 没有 commit 标识且存在对应的完整 binlog,说明在 commit 阶段发生了崩溃,此时实际上 redo log 和 binlog 都已经完整写入,可以提交事务。

 

4 为什么不能用 binlog 进行崩溃恢复

由于 binlog 记录的是写入性操作,如果想用 binlog 来恢复数据,我们必须知道现在得从哪里开始,因为一条语句多执行几次会带来数据上的错误。但是 binlog 虽然保存了所有的历史操作,但是它没有标识每条操作是否已经写入磁盘,所以我们确定从哪开始。

而 redo log 记录的是数据页的更改,并且刷盘完成的数据会从 redo log 中删除。

References:

  1. MySQL 实战 45 讲
  2. MySQL各种“Buffer”之Log Buffer

标签:

商匡云商
Logo
对比商品
  • 合计 (0)
对比
0
购物车