mysql探究-redolog和binlog的设计思路

mysql的更新流程，会牵涉到它的日志模块：redolog和binlog

redolog（重做日志）

redolog是Mysq的InnoDB引擎中才有的日志模块。

如果每次更改操作，都要进行一次日志磁盘写入，行数据磁盘更改，整个过程的IO就会很高，那InnoDB是怎么处理的呢？

当更新一条数据时，InnoDB会找到要更新的行数据，把做了什么修改记录写到redolog中，并把这行数据更新到内存中，整个过程就算完成了。

redolog是固定大小的（如下图），所以它只能循环记录做了什么修改，write pos为当前记录的位置，check point为当前可以擦除的位置，代表更新的行已经完成数据库的磁盘更改。如果前者速度，只能等待。

如果此时宕机了， 内存中更改后的行数据已经不再了， 但是redolog还是存在的，是可以恢复，这也就是mysql的crash-safe特性。

binlog（归档日志）

binlog存在Mysql的Server中，和引擎无关。

binlog记录的不是做了什么修改，而是真正记录了逻辑，比如 SET age = 2 WHERE ID =1。

binlog存储是追加型的，不会覆盖。

两个日志是如何交互在一起的？

以SET age = 2 WHERE ID =1为例， 顺序如下：

1. Server层调用引擎层先找到ID =1的数据（如果内存里有，直接内存返回）
2. 引擎层在内存中进行age改为2，同时将记录写到redolog，日志处于prepare状态
3. 整个更改完成，Server层写入一条binlog
4. Server层再调用引擎层提交事务，引擎层把刚刚写入的redolog改为commit状态。
5. 引擎层当空闲或timeout时，会对commit状态的redolog进行处理，将更新持久化到磁盘。

可以看到其中有两阶段的提交，好处在于上述任一环节中突然宕机，也能不受影响。

总结

binlog和redolog，两个分工明确，可以让我们提高更新效率，又能保证正常数据不丢失。分析redolog能知道当前引擎处理的饱和程度，通过binlog还能做更多业务处理。

我们的各种系统设计时，如果也很关注一致性，也可以借鉴此类方式。