Mysql 笔记二：redo log 和 binlog

使用sql语句进行数据库操作时，查询流程和更新流程不一样， 更新流程会涉及到两个重要的日志模块，redo log（重做日志）和 binlog（归档日志）。

redo log

引用一个例子：

不知道你还记不记得《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。

如果有人要赊账或者还账的话，掌柜一般有两种做法：

• 一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉；
• 另一种做法是先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。

在生意红火柜台很忙时，掌柜一定会选择后者，因为前者操作实在是太麻烦了。首先，你得找到这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。这整个过程想想都麻烦。相比之下，还是先在粉板上记一下方便。你想想，如果掌柜没有粉板的帮助，每次记账都得翻账本，效率是不是低得让人难以忍受？

在mysql中也会有这样一个问题，如果每一次的更新操作都需要写入到磁盘中，然后在磁盘中也要找到相对应的那条记录，然后执行更新操作，整个过程的io成本，查找成本都会很高。为了解决这个问题，mysql的设计者就用了类似酒店掌柜粉板的思路来提升更新的效率。

而粉板和账本配合的整个过程，其实就是mysql中常说到的WAL（write-ahead logging）技术，它的关键点就在于先写日志，再写磁盘，也就是对应掌柜的先写粉板，等到不忙的时候再写入账本的操作。

具体来说，当有一条记录需要更新的时候，innoDB 引擎就会先把记录写到redo log里，并更新内存，这里注意的是redo log也是记录在磁盘上的，虽然这也是一个写磁盘的过程，但是和更新数据库数据写磁盘的操作不一样在于更新数据库的操作是在磁盘上随机IO的操作，而写redo log的操作是顺序IO的操作，效率会更高，不然将redo log写入到内存中而不进行持久化的操作的话，这样的做法是没有意义的，在数据库宕机之后，redo log也就不存在了，则不能达到恢复数据库的目的。同时，innoDB 引擎会在适当的时候，将这个数据库的操作记录更新到磁盘里面，就像打烊了之后掌柜做的事情一样。

但是如果今天赊帐的人不多，掌柜可以等到打烊之后进行整理。但如果某天赊账的人特别多，粉笔写满了，又怎么办呢？这个时候掌柜的只好放下手中的活儿，把粉笔中的一部分赊账记录更新到账本上，然后再把这些记录从粉板上擦掉，为记新账腾出空间。

与此类似，innoDB的bin log的大小是固定的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。

write pos 是当前记录的位置，一边写一边后移，写到第三个文件末尾后就回到0号文件开头。 check point是当前要擦除的位置，也是往后推移并且是循环的，擦除记录之前要把记录更新到数据文件中，write pos和check point之间的内容就是还可以写的redo log的内存大小，当write pos追到check point之后，也就是说在每次redo log写满了之后，会把记录更新到数据文件中，也就是把mysql中表记录更新到磁盘文件上进行持久化，并且会把check point的位置往后推进。

有了 redo log，innoDB 就可以保证即使数据库发生了异常重启，之前提交的记录都不会丢失，这个能力被称为 crash-safe。

理解crash-safe这个概念，我们可以想想前面赊账记录的例子。只要赊账记录记在了粉板上或者写在了账本上，也就是我们记录了redo log并进行了持久化，之后即使掌柜忘记了，比如突然停业几天，恢复生意后依然可以通过账本和粉板上的数据明确赊账账目，对应的也就是我们数据库服务突然宕机重启，保存在内存中的数据还没来得及写入到磁盘上而丢失，我们也可以通过redo log进行数据的恢复。

binlog

之前提到的mysql整体看来是分为两层，一块是server层，它主要做的是mysql功能层面上的事情；还有一块是引擎层，负责存储相关的具体事宜。redo log是引擎层并且是innoDB引擎特有的日志，而server层也有自己的日志，称为binlog。

为什么会有两份日志？

redo log是innoDB引擎特有的，其他引擎，例如Memory，Mysiam没有的，其实就算是有binlog，按照现有的mysql的实现，他们也是不具备crash-safe的能力。因为redo log和binlog不同的地方在于redo log是一个固定大小，循环写的日志文件，它只会记录没有刷到磁盘中的日志，已经刷入到磁盘中的数据的redo log都会被删除。而binlog是追加日志，保存的是全量的日志，因此数据库在宕机恢复时，从binlog中并不能找到是从哪条binlog日志开始进行恢复刷盘。binlog日志只能用于归档，主从同步，redo log来实现crash-safe。

两种日志的不同点：

1. redo log是innoDB引擎独有的；binlog是Mysql在server层的实现，对于所有的引擎均能使用。

2. redo log是物理日志，记录的是在某个数据页做了什么修改； binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=x的这一行记录的x字段+1。

3. redo log是循环写的，空间固定；binlog是追加写入的，不会覆盖以前的日志。

两种日志的写入

引用例子：

有了对这两个日志的概念性理解，我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。

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

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

最后三步的设计，将redo log的写入拆成了两个步骤：prepare 和 commit，这就是两阶段提交。两阶段提交的设计思想在我们平时日常开发中也可以用到，用来保证业务上两个操作的一致性，类似数据库事务的操作，要么同时成功，要么同时失败，同时成功和同时失败，在redo log重放的时候体现。

两阶段提交

为什么需要两阶段提交呢？ 目的其实是为了让两份日志之间的逻辑保持一致。我们要思考一个问题：怎么样才能让数据库恢复到半个月内的任意一秒的状态？

之前我们说过的，binlog会记录所有的逻辑操作，并且采取的是追加写的方式。如果你的 DBA 承诺说半个月内可以恢复，那么备份系统中一定会保存最近半个月的所有 binlog，同时系统会定期做整库备份。这里的“定期”取决于系统的重要性，可以是一天一备，也可以是一周一备。注意这里恢复到某个时间点的数据库状态和crash-safe的关注点是不一样的，恢复到某个时间点的数据库状态一定是所有事务都是执行成功了的，这里的含义不是说数据库崩溃了，你要恢复到数据库崩溃之前的时间点。crash-safe的实现主要是依靠redo log的两阶段提交，如果仅仅依靠binlog是实现不了crash-safe的。举个例子，假如写入redo log prepare成功，然后写入binlog，这时候两个log都已经持久化到磁盘上去了，但是如果commit的时候，主数据库崩溃，但是从数据库已经开始消费崩溃时产生的binlog，则会造成主从不一致，这个时候就要靠redo log来进行恢复，主数据库重启之后，会重放redo log 他会检查redo log的状态，如果是处于prepare状态则会检查redo log上的记录的xid在已经写入磁盘的binlog上的相同的xid是否存在，如果存在则重新进行事务的提交，这个时候更改redo log的状态为commit。

我们为什么要使用两阶段提交？

这里不妨用反证法来进行解释。由于 redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写 binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。

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

使用 update 语句来做例子。假设当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？

1. 先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

2. 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

总结，本质上redo log负责事务，保证数据的完整性，一致性，binlog负责归档恢复。各司其职；相互配合，才保证了现有功能的完整性。