MySQL是如何做到异常重启还能保住数据的完整性

我就是我 2023-05-29 03:22 19阅读 0赞

## 前言 ##

#### redolog ####

redolog即重做日志，数据库安装目录下的data/ib\_logfile指的就是redolog文件。redolog作为一种对数据的恢复操作，恢复的是提交事务修改的页操作。  
如当我们执行下面的语句：

start transaction;
    select balance from bank where name="zhangsan";
    // 生成 重做日志 balance=600
    update bank set balance = balance - 400; 
    // 生成 重做日志 amount=400
    update finance set amount = amount + 400;
    commit;

对应的写redolog buffer以及redolog如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw_size_16_color_FFFFFF_t_70]  
当对数据表执行更新操作的时候，并不是直接写磁盘上的redolog文件，而是先写入redolog buffer即redolog缓冲区，然后在合适的时候刷新到磁盘，因为磁盘IO操作是很耗费性能的。  
还需要注意的是，虽然上图第三步骤说的是“记录（balance=600）到redolog”，不能理解为在redolog中记录的就是对某条数据的逻辑修改。redolog是物理日志，记录的是对页的修改操作。

## binary log ##

二进制日志，也称binlog，记录了对数据库只需更改的所有操作（不包括select和show这类操作），二进制日志的一个很重要的作用就是做数据恢复的时候用到，比如在一个数据库全备份文件恢复后，可以再通过二进制日志进行pinit-in-time的恢复。[《如何根据binlog恢复数据》][binlog]  
和redolog不同的是，binlog是逻辑日志，记录的是对具体某行数据修改的逻辑。  
知道了redolog和binlog的基本概念之后，进入正题。

#### redolog和binlog的区别 ####

*  二进制日志是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的，只记录该存储引擎中表的修改。
 *  二进制日志记录操作的方法是逻辑性的语句。即便它是基于行格式的记录方式，其本质也还是逻辑的SQL设置，如该行记录的每列的值是多少。而redo log是在物理格式上的日志，它记录的是数据库中每个页的修改。
 *  因为二进制日志只在提交的时候一次性写入，所以二进制日志中的记录方式和提交顺序有关，且一次提交对应一次记录。而redo log中是记录的物理页的修改，redo log文件中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1，可能在redo log中记录了 T1-1,T1-2,T1-3，T1\* 共4个操作，其中 T1\* 表示最后提交时的日志记录，所以对应的数据页最终状态是 T1\* 对应的操作结果。而且redo log是并发写入的，不同事务之间的不同版本的记录会穿插写入到redo log文件中，例如可能redo log的记录方式如下： T1-1,T1-2,T2-1,T2-2,T2\*,T1-3,T1\*。
 *  事务日志记录的是物理页的情况，它具有幂等性，因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的，例如新插入一行后又删除该行，前后状态没有变化。而二进制日志记录的是所有影响数据的操作，记录的内容较多。例如插入一行记录一次，删除该行又记录一次。

## MySQL是如何做到异常重启还能保住数据的完整性 ##

#### 两阶段提交![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw_size_16_color_FFFFFF_t_70 1] ####

两阶段提交指的就是上图中的prepare阶段和commit阶段（注意不要把这个commit和事务中的commit混淆），即当更新操作写入内存后，会继续写入redolog日志缓冲区中，此时该日志记录属于预提交阶段，然后再写入binlog中，等事务提交的时候再将redolog的状态变为commit状态。

#### 为什么要使用两阶段提交 ####

假设当前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，与原库的值不同。

## 使用两阶段提交如何正确恢复数据 ##

**在时刻A崩溃**  
如果在图中时刻A的地方，也就是写入redo log 处于prepare阶段之后、写binlog之前，发生了崩溃（crash），由于此时binlog还没写，redo log也还没提交，所以崩溃恢复的时候，这个事务会回滚。这时候，binlog还没写，所以也不会传到备库。到这里，大家都可以理解。  
**在时刻B崩溃**  
binlog写完，redo log还没commit前发生crash，那崩溃恢复的时候MySQL会怎么处理？  
先来看一下崩溃恢复时的判断规则：

*  如果redo log里面的事务是完整的，也就是已经有了commit标识，则直接提交；
 *  如果redo log里面的事务只有完整的prepare，则判断对应的事务binlog是否存在并完整：  
    a. 如果是，则提交事务；  
    b. 否则，回滚事务。

这里说的在时刻B崩溃恢复指的就是2a步骤，因为binlog已经写完，从备库恢复到具体某个时间点的时候binlog中的记录肯定都会恢复到备库中，因此，肯定要把事务提交了，才能保证当前时间和备库恢复到时间点的时候数据是一样的。

## 数据更新到磁盘是由读取redo log的还是buffer pool ##

1.  如果数据库正常运行，调入内存的数据页和磁盘的数据页不一致，这一页称为“脏页”。数据最终更新到磁盘中，就是直接把内存中的数据页写入磁盘，不需要用到redo log。
2.  如果是数据库崩溃恢复的场景，InnoDB如果判断到一个数据页可能在崩溃恢复的时候丢失了更新，就会将该页读入内存，然后利用redo log更新内存中的数据，更新完后，内存也变为脏页，就回到了第一种状态。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2019110220390658.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw,size_16,color_FFFFFF,t_70
[binlog]: https://www.cnblogs.com/lihan829/p/11408061.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191102214649706.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0lUXzEw,size_16,color_FFFFFF,t_70