图解MySQL【日记】——Redo Log

打印 上一主题 下一主题

主题 887|帖子 887|积分 2661

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企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

滴水恩情

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表