MySQL日志之redo log和binlog

女爷i 2022-10-29 13:28 176阅读 0赞

## 前言 ##

只要是接触过MySQL的程序员，那么或多或少都有听过redo log（重做日志）和binlog（归档日志）。今天就来分享一下这两个日志的用处和区别。

简单来说，redo log是InnoDB特有的日志，如果使用的是其他存储引擎，就没有redo log，只有binlog。

binlog是MySQL的Server层的日志，不管使用什么存储引擎，都会有binlog的存在。那么，为什么要有redo log和binlog呢？一个binlog不就可以全部解决了吗？接下来我们就来详细看一下redo log和binlog的区别吧。

## redo log ##

redo log称为重做日志，用于记录事务的变化，记录的是数据被修改之后的值。InnoDB采用redo log来保证事务更新的一致性和持久性。

在MySQL中，如果你要更新一条语句，需要带更新条件，比如update T set name = ‘god-jiang’ where id=6，一般都是先查询到id=6的语句，然后再进行更新操作。

如果更新的数量是100条，1000条甚至10000条的时候，每一次更新都需要写到磁盘上。然后磁盘也要找到对应的记录，然后再更新，整个过程IO成本、查找成本太大，为了解决这个问题，MySQL的设计者采用了WAL技术来解决。WAL全称是Write Ahead Logging，意思就是**先写日志，再写磁盘**。

具体操作：当有一条记录需要更新的时候，InnoDB引擎会先把记录写到redo log中，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候（系统空闲时），将这个操作记录更新到磁盘中，这个更新往往是在系统比较空闲的时候。

但是redo log的大小是固定的，不可能一直无限写，让我们看下MySQL怎么做到的吧。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzY4NjQxNQ_size_16_color_FFFFFF_t_70]

MySQL使用的是write pos和check point搭配循环写保证数据都能及时的更新到磁盘中。

write pos是当前记录的位置，一边写一边往后移动。check point是当前要擦除的位置，也是往后移动并且循环的，擦除记录之前要把记录更新到数据文件中。

当ib\_logfile\_3写满了之后就会回到ib\_logfile\_0继续写。而ib\_logfile\_x都是可以通过MySQL来配置分组，但是配置的redo log大小是固定的。

write pos与check point之间的部分表示可以记录新的操作。如果write pos追上了check point，表示redo log满了，这个时候就不能继续执行新的操作，需要停下擦除一些记录，并且把check point往后推进。

有了redo log，InnoDB可以保证即使数据库发现异常重启了，也不会丢失之前提交的事务，这个能力也被称为crash-safe。

以上就是redo log的介绍，看完了之后，你可以试着去问一下你公司的DBA同事，MySQL是否可以恢复到半个月内任意一秒的状态，得到的答案肯定是可以的，这都要归功于redo log的功劳。

## binlog ##

binlog记录了所有DDL（数据定义语句）和DML（数据操纵语句），但是不包括select和show。

binlog主要用来进行POINT-IN-TIME（PIT）的恢复及主从复制环境的建立。从表面上看它和redo log非常相似，都是记录了对于数据库操作的日志，但是从本质上看，还是有着非常大的不同。

### redo log和binlog的区别 ###

*  首先，redo log是在InnoDB存储引擎层产生，而binlog是在数据库上层产生的，并且binlog不仅仅针对InnoDB存储引擎，MySQL数据库中任何存储引擎都会产生binlog
 *  其次，两种日志的内容记录不同。binlog是一种逻辑日志，其记录的是对应的SQL语句，而redo log是一种物理日志，其对应的是对于每个页的修改
 *  最后，两种日志写入磁盘的时间点不同，binlog只在事务提交完成后进行一次写入，而redo log在事务进行中不断的写入，表现为不是随事务提交的顺序写入
 *  binlog一般作为恢复数据使用，主从复制搭建，而redo log通常作为MySQL异常宕机或者介质故障后的数据恢复使用

**通过简单的更新语句演示执行器和InnoDB引擎的内部流程**

update T set name = 'god-jiang' where id = 6

1.  通过执行器从InnoDB引擎取出id=6的记录，然后加载到内存中
2.  执行器拿到引擎返回的结果，把name修改为’god-jiang’，再重新调用存储引擎的接口写入新数据
3.  引擎将新数据更新到内存中，同时将这个更新操作写到redo log中，此时redo log处于prepare状态
4.  执行器生成这个操作的binlog，并把binlog写到磁盘中
5.  执行器调用引擎提交事务的接口，并且把刚刚写入的redo log改为commit状态，更新完成

**对应的流程图**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzY4NjQxNQ_size_16_color_FFFFFF_t_70 1]

最后为什么写入redo log会处于prepare状态，然后写入binlog还要变成commit状态？其实这个过程就叫做“两阶段提交”。

## 两阶段提交 ##

其实redo log和binlog都可以用于表示事务的提交的状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

举例子：update T set name = ‘god-jiang’ where id = 6没有两阶段提交会发生什么？

先写redo log后写binlog。假设写完了redo log，binlog还没有写完，这个时候MySQL异常重启。因为redo log写完了，恢复系统的时候name=‘god-jiang’。但是binlog没有写完，所以binlog没有记录这条语句，这个时候用binlog恢复数据的时候，恢复出来的name就是原来值，与redo log不同。

同理可得，先写binlog后写redo log也会发现两个日志恢复的数据不同。这个不一致会导致线上出现主从不一致的情况。

## 总结 ##

*  redo log可以保存crash-safe能力，可以保证MySQL异常重启数据不丢失
 *  binlog可以记录对应的SQL语句，也可以保证MySQL异常重启数据不丢失
 *  提交事务的两阶段提交，可以维持数据逻辑一致性

## 参考资料 ##

*  《MySQL实战45讲》 林晓斌
 *  《高性能MySQL》第三版 1.3 事务
 *  《MySQL技术内幕》第二版 7.2事务的实现

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzY4NjQxNQ_size_16_color_FFFFFF_t_70]: /images/20221024/fd737698b0d842d7830c64a5eb19510f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzY4NjQxNQ_size_16_color_FFFFFF_t_70 1]: /images/20221024/a6d4958c390d4ee98de5b45ed42901a4.png