455-MySQL(redo log重做日志)

小咪咪 2022-09-07 01:31 176阅读 0赞

当事务提交之后，不管MySQL server会出现什么不可预期的错误，哪怕是进程挂了，断电了，只要事务提交成功，由MySQL处理完异常后把数据恢复  
![在这里插入图片描述][de3597c62ece4bf5ace02c6a3359dac2.png]  
![在这里插入图片描述][a3c9e96d32d94be495cc39b4d428abd1.png]

## redo log 重做日志 ##

**redo log**：重做日志，用于记录事务操作的变化，**确保事务的持久性。**  
**redo log是在事务开始后就开始记录（并不是事务commit时才记录，而是事务begin开始后就记录）**，不管事务是否提交都会记录下来，在异常发生时（如数据持久化过程中掉电）**，InnoDB会使用redo log恢复到掉电前的时刻，保证数据的完整性。**

**innodb\_log\_buffer\_size默认是16M，就是redo log缓冲区的大小**，它随着事务开始，就开始写redolog，如果事务比较大，为了避免事务执行过程中花费过多磁盘IO，**可以设置比较大的redo log缓存，节省磁盘IO。**  
InnoDB修改操作数据，不是直接修改磁盘上的数据，**实际只是修改Buffer Pool中的数据**。InnoDB总是先把Buffer Pool中的数据改变记录到redo log中，用来进行崩溃后的数据恢复。 **优先记录redo log，然后再慢慢的将Buffer Pool中的脏数据刷新到磁盘上。**  
innodb\_log\_group\_home\_dir指定的目录下的两个文件：ib\_logfile0，ib\_logfile1，该文件被称作**重做日志。**  
**buffer pool缓存池：**（B+树索引，自适应哈希）  
**作用**：加速读和加速写，直接操作data page，写redo log修改就算完成，有专门的线程去做把buffer pool中的dirty page写入磁盘。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]  
**弧形**：奔溃的恢复。  
MySQL server：检查一些连接，SQL的优化操作  
然后就是存储引擎  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]  
黄色的柱状就是磁盘  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]  
**左边绿色的是日志缓存，专门的重做日志的缓存，不可能直接往磁盘上写，最终记录在磁盘上。  
右边绿色的就是缓存池，就是数据缓存，索引缓存，最终发送到磁盘上。**

当我们在数据更新的时候，事务开始以后，随着事务执行一些相应的SQL，这些对数据的更改都是先记录在redo log buff里面，对于数据或者索引的修改都是先记录在buff poll里面。  
当我们提交事务的时候，关系图上的操作就是把InnoDB Log Buffer的内容写入磁盘，写成功的话，在磁盘上的redo log会记录状态：commit，如果没有写成功或者写完，就是：prepare  
**在写入磁盘的过程中也有可能发生异常，掉电，服务崩溃，导致在写redo log的时候没有写完，出错了，相当于事务没有提交成功，MySQL下次在恢复的时候就没有必要考虑这个事务的完整性，因为状态并不是commit，都写入磁盘上才表示redo log写成功，状态变成commit。**

**是不是commit的时候，buff poll里面的脏数据写入磁盘？**  
并不需要和commit操作同步。  
进入数据修改的时候，对于buff poll缓存的数据，**我们有专门的线程核实时间，往磁盘去刷新，如果出现掉电，下一次mysql启动后，会根据redo log里面记录的数据，对数据进行恢复**。**undo log也要记录在redo log中**  
undo log支持事务回滚，也不是一瞬间就发生了，最终要修改的也是磁盘上的数据，要防止在回滚中出现异常，所以要记录在redo log里面。  
**事务commit成功或者rollback成功，对于底层，都是成功的把操作写到redo log里面。**

**当我们去事务commit成功的时候，最重要的是写redo log成功刷新到磁盘上，把数据的状态改为commit，这才算真真正正的事务提交成功，最重要的不是写数据到磁盘。**  
**redo log**里面记录的就是最终修改后的按页面存储的数据页（物理日志）。

**undo log**是逻辑日志，存储的是具体SQL语句

**默认16M**  
![在这里插入图片描述][f7235722b17f4eb68aea3f33fc6ba27a.png]  
**重做日志**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]  
优先修改缓存池中的东西  
**看看buff pool的大小**  
134M  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]  
**当我们在进行事务更改的时候，永远先写的是redo log，然后才是写buff pool，当事务提交成功，就是要保证redo log就记录完整到磁盘上。  
对于表数据的更改，buff pool的脏数据是不是刷新到磁盘上，我们不用担心，因为我们可以随时通过redo log来恢复事务提交成功的状态。**

[de3597c62ece4bf5ace02c6a3359dac2.png]: /images/20220829/af57d7205431426aacf718b1125c6a13.png
[a3c9e96d32d94be495cc39b4d428abd1.png]: /images/20220829/116fd116aeed414e87609a033a564188.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]: /images/20220829/e33549114f5e461d950ef51649ce2ddd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]: /images/20220829/26dafdd3dfde453d8393a24105af0c77.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]: /images/20220829/74be357c84c0409486ff8c024cb3eb6d.png
[f7235722b17f4eb68aea3f33fc6ba27a.png]: /images/20220829/f62334036c2246839581ba1ab8cfc472.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]: /images/20220829/5e5aeccfcf7343889fab7beda9f35a82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]: /images/20220829/8bf468e5a20842ba846bb72af5b8f3bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]: /images/20220829/d5e3effa455643b0bc82dded7231e601.png