MySQL的InnoDB存储引引擎的物理文件存储体系中,除了实际的数据文件(ibd ibdata)之外,还有两个非常重要的日志系统,分别是重做日志和撤销日志。跟甲骨文类似,重做日志记录了对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更).InnoDB也是采用了细胞膜(日志优先落盘),也就是说在实际数据文件的修改落盘之前重做日志已经落盘,从而来保证事务的持久性.Undo日志用来保证事务的原子性和MVCC,所有的撤销操作产身的数据文件的变更也会记录到重做日志中。
在原生的MySQL中,重做日志不会用来做物理主从复制,其主要的应用场景是用来进行MySQL的崩溃Recovey(崩溃恢复)。关于MySQL InnoDB的崩溃恢复会在后续的文章中进行介绍。
本文主要基于MySQL 8.0介绍重做日志的基本构成。
<强> 1。,,重做日志文件
从MySQL 5.6开始,已经废弃了日志组的特性(重做日志可以写多份),网上有观点认为可能是InnoDB的开发团队认为用外层的存储硬件来保证日志组的完整性可能更好一些。同时从5.7开始InnoDB的归档日志档案也被放弃(归档日志用来归档存放所有的重做日志,重做日志系统内是采用固定尺寸的多个日志文件循环写的方式来存放重做日志,如果写满了会循环到开始的位置开始写入)。
不过MySQL 8.0引入一个称之为克隆的机制,从代码的角度来看,似乎是用来实现远程克隆一个当前数据库的副本,在这个机制中又引入的新的存档归档机制。如果读者有兴趣可以阅读一下MySQL8.0新版本源码的存储\ innobase \拱和存储\ innobase \克隆目录下的代码。
<强> 1.1。,重做日志相关参数
innodb_log_group_home_dir
该参数用来指定重做日志存放的路径,日志文件以ib_logfile[数字]来命名。
innodb_log_files_in_group
虽然MySQL已经放弃了日志组的概念,但参数名依旧保留了下来以兼容以前的配置。该参数的含义为有多少个日志文件(最少为2个)。
innodb_log_file_size
表示每个文件的大小。
所以,总的重做日志的大小为innodb_log_files_in_group * innodb_log_file_size。
<强> 1.2。,重做日志循环写
重做日志以顺序的方式写入文件,当全部文件写满的时候则回到第一个文件相应的起始位置进行覆盖写(但在做重做检查点时,也会更新第一个日志文件的头部检查点标记,所以严格来讲也不算顺序写),在InnoDB内部,逻辑上重做日志被看作一个文件,对应一个空间id (InnoDB通过空间的概念来组织物理存储,包括不同的表,数据字典,重做,撤销等)。
上图是以指定innodb_log_files_in_group为3的循环写的情况。
<强> 2。,,重做日志存储格式简介
尽管重做日志有多个文件,但每个文件的组成结构是一样的,只是有一些数据只会存在的第一个日志文件(ib_logfile0)的文件头中,例如缓冲池冲洗检查点信息只会写在第一个日志文件的文件头中。
<强> 2.1。,日志文件存储结构概览
重做日志进行MySQL的崩溃Recovey(崩溃恢复)解析
