开始MySQL之路——MySQL三大日志(binlog、redo log和undo log)概述详解

末蓝、 2024-03-26 23:23 14阅读 0赞

### 前言 ###

MySQL实现事务、崩溃恢复、集群的主从复制，底层都离不开日志，所以日志是MySQL的精华所在。只有了解MySQL日志，才算是彻底搞懂MySQL。

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。

我们重点需要关注的是MySQL的三大日志系统**：Redo Log（重做日志）**、**Undo Log（恢复日志）**、**Bin Log（二进制日志文件）**。

### **一、Redo Log（重做日志）** ###

#### 1.1为什么需要redo log ####

事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

*  因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了
 *  一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差

因此mysql设计了redo log，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

**作用概述：**Redo Log就是用来保证服务崩溃后，仍能把事务中变更的数据持久化到磁盘上。

MySQL事务中持久性就是使用**Redo Log**实现的。

#### **1.2什么时候写入Redo Log？** ####

![1d9627bf60774dfbb15a62319858405a.png][]

1.  从磁盘加载数据到内存
2.  在内存中修改数据
3.  把新数据写到**Redo Log Buffer**中
4.  把**Redo Log Buffer**中数据持久化到**Redo Log**文件中
5.  把**Redo Log**文件中数据持久化到数据库磁盘中

你可能会问，为什么需要写**Redo Log Buffer**和**Redo Log FIle**？直接持久化到磁盘不好吗？

直接写磁盘会有产生严重的性能问题：

> 1.  InnoDB在磁盘中存储的基本单元是页，可能本次修改只变更一页中几个字节，但是需要刷新整页的数据，就很浪费资源。
> 2.  一个事务可能修改了多页中的数据，页之间又是不连续的，就会产生随机IO，性能更差。

这种方案叫做WAL（Write-Ahead Logging），预写日志，就是先写日志，再写磁盘。

#### 1.3redo log基础概述 ####

redo log包含了两个层面：

1.  内存层面（redo log buffer）重做日志的buffer，由redolog block组成，一个16MB
2.  物理磁盘层面 (redolog file) 重做日志文件id\_logfile0,id\_logfile1

redolog的整体流程：

![1cbbbd427d418fa15627e892e76f93bc.png][]

还没提交就在写log。redolog的优先级跟高。

注意：redo log buffer刷盘到redo logfile的过程并不是真正的刷盘，只是刷入到文件缓存中（这个是操作系统提高文件写入效率的优化）。

但是这种就会出现交给系统，刷盘不及时，宕机造成数据丢失。

#### **1.4redo log刷盘规则** ####

写入**Redo Log Buffer**之后，并不会立即持久化到**Redo Log FIle**，需要等待操作系统调用fsync()操作，才会刷到磁盘上。

![9ea78a2e793546e18acff66f9b8d79a9.png][]

具体什么时候可以把**Redo Log Buffer**刷到**Redo Log FIle**中，可以通过**innodb\_flush\_log\_at\_trx\_commit**参数配置决定。

<table> 
 <tbody> 
  <tr> 
   <th>参数值</th> 
   <th>含义</th> 
  </tr> 
  <tr> 
   <td>0（延迟写）</td> 
   <td>提交事务后，不会立即刷到OS Buffer中，而是等一秒后刷新到OS Buffer并调用fsync()写入Redo Log FIle，可能会丢失一秒钟的数据。</td> 
  </tr> 
  <tr> 
   <td>1（实时写</td> 
   <td>每次提交事务，都会刷新到OS Buffer并调用fsync()写到Redo Log FIle，性能较差</td> 
  </tr> 
  <tr> 
   <td>2（延迟刷新）</td> 
   <td>每次提交事务只刷新到OS Buffer，一秒后再调用fsync()写入Redo Log FIle。</td> 
  </tr> 
 </tbody> 
</table>

InnoDB 的**Redo Log File**是固定大小的。可以配置为每组4个文件，每个文件的大小是 1GB，那么**Redo Log File**可以记录4GB的操作。

采用循环写入覆盖的方式，write pos记录开始写的位置，向后移动。checkpoint记录将要擦除的位置，也是向后移动。write pos到checkpoint之间的位置，是可写区域，checkpoint到write pos之间的位置是已写区域。

![635981df1dca4c2084ee00278bd80e0c.png][]

Redolog小结： ![1ae08f3bebfe43578226e88afa9fe079.png][]

#### 1.5redo log与binlog区别 ####

由bin log和redo log的区别可知：

*  bin log日志只用于归档，只依靠bin log是没有crash-safe能力的。但只有redo log也不行，因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要bin log和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。
 *  redolog是存储引擎层产生的，而binlog 是数据层层面产生的。假设一个事务，对表做了10万行的记录插入，在这个过程中，一直不断的往redo log顺序记录，而bin log不会，只有事务提交后才一次性写入binlog日志。
 *  功能：redo log:让innodb存储引擎拥有崩溃恢复能力，bin log:保证了Mysql集群架构的数据一致性。

### **二、Undo Log（恢复日志）** ###

#### 2.1为什么引入undo log? ####

为了保证事务的原子性（既事务中的操作要么全部做完，要么都不做）。如果事务执行中突发异常，如数据库出错、操作系统宕机等，亦或者程序员要在事务执行过程中结束当前事务的执行，如何保证事务的原子性呢？

这就需要在对一条记录做变更（增删改，不包括查）时，都要把能回滚的内容记录下来以备不时之需，回滚的时候只需要对数据库进行一个相反的操作即可。

*  新增一条记录，记录下主键，回滚时直接`DELETE`这个主键的内容;
 *  删除一条记录，记录下被删记录的内容，回滚时可以将内容再插入表中；
 *  修改一条记录，记录下修改之前的旧值，回滚时直接更新为旧值。

#### 2.2undo log的作用 ####

*  回滚数据：`undo log`记录了每个操作的逆操作，可以逻辑恢复数据（注意：类似git 操作，不是物理上的恢复，既数据结构和页可能变化了）；
 *  `MVCC`：在`InnoDB`中`MVCC`的实现是通过`undo log`来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过`undo log`读取之前的行版本信息，以此实现非锁定读取。

#### 2.3undo log的类型 ####

在InnoDB中，undo log分为两种：

*  `insert`undo log：是指在`insert`操作中产生的undo log。因为`insert`操作的记录，只对当前事务本身可见，对其他事务不可见(这是事务隔离性的要求)，因此这种`undo log`可以在事务提交后直接删除。不需要进行`purge`操作。
 *  `undate`undo log：是对`delete`和`update`操作产生的undo log。该undo log可能需要提供`MVCC`机制使用，因此不能在事务提交时就进行删除，提交时放入undo log`链表`，等待`purge`线程进行最后的删除。

#### 2.4undo log的生命周期 ####

![7110f3ccc0eb4a0daf1a97d7acf17ef3.png][]

MySQL处于性能考虑，数据会优先从磁盘加载到`Buffer Pool`中，在更新`Buffer Pool`中数据之前，会优先将数据记录到`undo log`中。

记录`undo log`日志，MySQL不会直接去往磁盘中的`xx.ibdata`文件写数据，而是会写在`undo_log_buffer`缓冲区中，因为工作线程直接去写磁盘太影响效率了，写进缓冲区后会由后台线程去刷写磁盘。

#### 2.5删除过程 ####

现在我们已经明白了`undo log`日志是如何生成，并且作用于事务回滚的，那这些数据是什么时候删除呢？

*  针对于`insert undo log`，因为`insert`操作的记录，只对事务本身可见，对其他事务不可见。故该`undo log`在事务提交后就没有用，就会直接删除。
 *  针对于`update undo log`，该`undo log`需要支持`MVCC`机制，因此不能在事务提交时就进行删除。提交时放入`undo log`链表，有专门的`purge`线程进行删除。

### **三、Bin Log（**二进制日志文件**）** ###

#### 3.1bin log基本概述 ####

即`binary log`，二进制日志文件，也叫作变更日志（`update log`），是`MySQL`中比较重要的日志，和运维息息相关。它记录了所有更新数据库的语句（如`DDL`和 `DML`语句）并以二进制的形式保存在磁盘中，但是不包含没有修改任何数据的语句（如数据查询语句select、show等）。

`bin log`是逻辑日志，记录的是执行语句的逻辑，和`redis`的`AOP`日志类似，会按顺序记录所有涉及更新数据的逻辑操作。

#### **3.2主要作用** ####

*  数据恢复：`MySQL`可以通过`bin log`恢复某一时刻的误操作的数据，是`DBA`常打交道的日志。
 *  数据复制：`MySQL`的数据备份、集群高可用、读写分离都是基于`bin log`的重放实现的。

![b2dda30dad06492a819c54329132dd5e.png][]

#### 3.3记录格式 ####

binlog日志有三种格式：`statement`、`row`和`mixed`，对比如下：

<table> 
 <tbody> 
  <tr> 
   <th>格式</th> 
   <th>含义</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
  <tr> 
   <td>statement</td> 
   <td style="text-align:justify;">每一条会修改数据的sql都会记录在binlog中,基于SQL语句的复制，记录的是更新数据操作的SQL语句，这些语句同步时会被其他节点执行，如update T set time=NOW() where id = 1;</td> 
   <td style="text-align:justify;">不需要记录每一行的变化，减少了binlog日志量，节约了IO, 提高了性能。</td> 
   <td style="text-align:justify;">由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行的时候相同的结果。另外mysql的复制，像一些特定函数的功能，slave与master要保持一致会有很多相关问题。</td> 
  </tr> 
  <tr> 
   <td>row</td> 
   <td style="text-align:justify;">5.1.5版本的MySQL才开始支持 row level 的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。</td> 
   <td style="text-align:justify;">binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以row的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。</td> 
   <td>每条数据的更改被详细记录，如整表删除，alter表等操作涉及的数据行都会记录，ROW格式会产生大量日志。</td> 
  </tr> 
  <tr> 
   <td>mixed</td> 
   <td>混合模式，5.1.8版本开始，以上两种格式的混合版，对于DDL只对SQL语句进行记录，对DML操作则会进行判断，如果判断会造成主从不一致，就会采用row格式记录，反之则用statement格式记录。</td> 
   <td>既节省空间，又提高数据库性能，保证数据同步时的一致性。</td> 
   <td>无法对误操作数据进行单独恢复。</td> 
  </tr> 
 </tbody> 
</table>

注：将二进制日志格式设置为ROW时，有些更改仍然使用基于语句的格式，包括所有DDL语句，例如CREATE TABLE， ALTER TABLE，或 DROP TABLE。

#### **3.4Binlog结构和内容** ####

日志由一组二进制日志文件（Binlog)，加上一个索引文件（index）；Binlog是一个二进制文件集合，每个Binlog以一个4字节的魔数开头，接着是一组Events。

1.  魔数：0xfe62696e对应的是0xfebin
2.  Event：每个Event包含header和data两个部分；header提供了Event的创建时间，哪个服务器等信息，data部分提供的是针对该Event的具体信息，如具体数据的修改
3.  第一个Event用于描述binlog文件的格式版本，这个格式就是event写入binlog文件的格式
4.  其余的Event按照第一个Event的格式版本写入
5.  最后一个Event用于说明下一个binlog文件
6.  Binlog的索引文件是一个文本文件，其中内容为当前的binlog文件列表

[1d9627bf60774dfbb15a62319858405a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/a04d2a5b487349849b370ef19b56293c.png
[1cbbbd427d418fa15627e892e76f93bc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/d08345fdb6f34eb48a08dbd55a6f807c.png
[9ea78a2e793546e18acff66f9b8d79a9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/063eecd2fa1746ec9d4b8418d76af822.png
[635981df1dca4c2084ee00278bd80e0c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/30dfd0b165a241f8b73ebcecca25dfef.png
[1ae08f3bebfe43578226e88afa9fe079.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/d132a838bde046a79679e5522c64e28e.png
[7110f3ccc0eb4a0daf1a97d7acf17ef3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/a9f7629881d14d21a2b86ce22d7472c4.png
[b2dda30dad06492a819c54329132dd5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/e143803e67b4448fa0f42833805fb686.png