图解MySQL【日记】——Redo Log

Redo Log（重做日记）

为什么必要 Redo Log？

1. 瓦解恢复

• 数据库瓦解时，系统通过 Redo Log 来恢复尚未写入磁盘的数据。Redo Log 记录了所有已提交变乱的利用，系统在重启后会重做这些利用，以包管数据不会丢失。
  
• 
  
  

---

2. 进步性能

• 使用 Redo Log 可以制止每次修改都立即写入磁盘（随机写），而是先将修改利用写入 Redo Log（顺序写），然后将数据写入内存，末了再异步地将数据写入磁盘，镌汰了磁盘 I/O 的次数，进步了性能。
  

3. 变乱同等性

• 纵然数据库在实行过程中瓦解，Redo Log 也可以帮助恢复所有已提交的变乱，确保数据库恢复到同等（Consistency）的状态。
  

---

Redo Log 是什么？

• Redo Log 是物理日记，记录了某个数据页做了什么修改，如对 AAA 表空间中的 BBB 数据页 CCC 偏移量的地方做了 DDD 更新，每当实行一个变乱，就会产生一条或多条物理日记。
  
• 在变乱提交时，只要包管 Redo Log 被持久化到磁盘即可，可以不必要比及将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。纵然系统瓦解，Redo Log 已完成持久化，等待 MySQL 重启后，可以根据 Redo Log 的内容，将所有数据恢复到最新状态。
  

---

WAL（Write-Ahead Logging）技术

核心思想

• 先写日记：修改数据之前，先将修改利用记录到日记文件中，之后择机再写到磁盘中。
  
• 瓦解恢复：这样纵然瓦解，数据也能通过日记恢复到同等的状态。
  
• 顺序写 VS 随机写：Redo Log 采用顺序循环写的方式，写入磁盘的速率远大于直接写入磁盘的顺序写方式。
  

---

过程如图

---

Redo Log 的持久化过程

1. Redo Log Buffer

• 在变乱实行过程中，产生的 Redo Log 也不是直接刷盘的，而是先写入 Redo Log Buffer，后续再择机刷入磁盘中。
  
• 默认巨细为 16MB，可通过 innodb_log_Buffer_size 参数动态调解巨细，增大时，可以让 MySQL 处置处罚【长变乱】时不必写入磁盘，提拔写 I/O 性能。
  
• 
  
  

---

2. Redo Log 什么时间刷盘？

缓存在 Redo Log Buffer 中的 Redo Log 还是在内存中，刷盘时机如下：

• MySQL 正常关闭时。
  
• Redo Log Buffer 中记录的写入量大于总内存空间（由 innodb_log_Buffer_size 控制）的一半时，触发落盘。
  

• 
  
  
  
  • 超过一半就落盘的原因：在性能和数据安全之间找到一个平衡点。
    
  
  

• InnoDB 的后台线程每隔 1s，将 Redo Log Buffer 持久化到磁盘。
  
• 每次提交变乱时，将 Redo Log Buffer 持久化到磁盘，由 innodb_flush_log_at_trx_commit 参数控制。
  

---

3. innodb_flush_log_at_trx_commit 参数

决定 Redo Log 的刷盘时机。
0 ：每次变乱提交，将 Redo Log 留在 Redo Log Buffer 中，该模式下，变乱提交时不会主动触发落盘利用。

• 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，先写入 OS 的 Page Cache，后调用 fsync() 持久化到磁盘。
  
• 数据安全性：MySQL 瓦解时，会导致上 1s 所有变乱数据丢失。
  

---

1（默认）：每次变乱提交，将缓存在 Redo Log Buffer 中的 Redo Log 直接持久化到磁盘中。

• 安全性：该模式可以包管 MySQL 异常重启后，数据不会丢失。
  

---

2：每次变乱提交时，都只将缓存在 Redo Log Buffer 中的 Redo Log 写到 Redo Log 文件（OS 的 Page Cache，系统文件缓存），而非磁盘。

• 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，调用 fsync() 将 Page Cache 中的 Redo Log 持久化到磁盘。
  
• 数据安全性：MySQL 瓦解时不会导致数据丢失，只有在 OS 瓦解或系统断电的情况下，丢失上 1s 所有事物数据。
  

---

数据安全性对比：参数 1 > 参数 2 > 参数 0

---

写入性能对比：参数 1 < 参数 2 < 参数 0

---

每种参数对应的写入过程

4. Redo Log 怎样写入？

重做日记文件组（Redo Log Group）：

• 默认情况下，InnoDB 存储引擎有一个 Redo Log Group，该重做日记文件组由 2 个 Redo Log 文件构成，且每个 Redo Log File 的巨细固定且同等，如下图
  
  
  

---

循环写：

• Redo Log Group 是以循环写方式工作的，即重新开始写，写到末尾再循环到开头，相称于环形。
  

• 具体过程：Redo Log 是制止防止 Buffer Pool 中的脏页丢失而设计的，但随着系统运行，Buffer Pool 中的脏页逐步被刷新到磁盘中，Redo Log 也必要更新本身的空间，擦除已刷新到磁盘中的旧记录，为新的脏页数据腾出空间。
  
  
  

• 
  
  
  
  • write pos：Redo Log 当前记录写到的位置。
    
  • check point：表示当前要擦除的位置。
    
  • write pos~check point（赤色部分）：用来记录新的更新利用。
    
  
  

• 
  
  
  
  • 
    
    
    
    • write pos 追上 check point 时表示 Redo Log 文件已满，这时 MySQL 不能实行新的更新利用，即被壅闭（故大并发量的系统，将 Redo Log 文件巨细设置为适当的值很有必要），此时会停下来将 Buffer Pool 中的脏页数据刷新到磁盘中，然后标记 Redo Log 哪些记录可以被擦除，接着对旧 Redo Log 记录举行擦除，等擦除完成并腾出空间后，check point就会以后移动，MySQL 恢复正常，继续实行新的更新利用。
      
    
    
  
  

• 
  
  
  
  • check point~write pos（蓝色部分）：待落盘的脏数据页记录。
    
  
  

• 
  
  
  
  • 
    
    
    
    • 一次 check point 的过程就是脏页数据刷新到磁盘中酿成干净页，然后标记 Redo Log 记录中哪些记录可以被覆盖的过程。
      
    
    
  
  

---

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告