Innodb丶Recovery
背景
InnoDB作为事务性引擎,使用write-ahead logging(WAL)机制保证ACID中的Atomicity和Durability,使用undo机制保证ACID中的Consistency和Isolation。
按照WAL和undo的机制,形成以下两个原则:
- 数据块的更改需要先记录redo日志。
-
数据块的更改需要先写入undo。 根据这两个原则,InnoDB更新数据的基本流程可以简单的总结为:
- 记录需要更改undo record的redo log
- 记录需要更改data record的redo log
- 写入redo log
- 写入undo record
- 更新data record 这5个步骤。
InnoDB Recovery
如果MySQL实例异常crash,那么重启过程中首先会进行InnoDB recovery。 即:根据last checkpoint点,顺序读取后面的redo log,按照先前滚,再回滚的原则, 应用所有的redo log。
因为redo record中记录着数据块的地址(space_id+page_no),所以recovery的过程首先会执行合并相同数据块的操作,以加快recovery的过程。
那么问题来了
根据space_id怎么找到对应IDB数据文件? 因为在恢复的过程中,InnoDB只load了redo文件和系统表空间文件,如何查找InnoDB的数据文件呢?
- InnoDB的数据字典dict_table_t结构中也保存了对应关系,但数据字典受redo保护,recovery的过程中不可用。
- 扫描datadir的所有数据文件,读取page中保存的space_id,建立space_id和数据文件的对应关系。 MySQL目前采用第二种方式,但带来了一个问题,当设置了innodb_file_per_table后,每一个表对应一个表空间,那么需要读取所有的目录下的所有Innodb数据文件,这样就会严重的影响了recovery的时间。
MySQL 5.7改进策略:
MySQL 5.7中,在redo log中增加了一种新的record类型,即MLOG_FILE_NAME,记录了自last checkpoint以来更改的数据文件的file name。 这样在应用的时候,直接根据文件名就可以找到数据文件。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?