MySQL InnoDB redo Log 浅析

本文深入解析MySQL InnoDB存储引擎的Redo日志系统,包括Redo日志的循环写机制、存储格式、MTR记录及其实现事务持久性的关键作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

MySQL的InnoDB存储引引擎的物理文件存储体系中,除了实际的数据文件(ibd, ibdata)之外,还有两个非常重要的日志系统,分别是redo日志和undo日志。 跟Oracle类似, redo log记录了对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更)。InnoDB也是采用了WAL(日志优先落盘),也就是说在实际数据文件的修改落盘之前redo日志已经落盘,从而来保证事务的持久性。Undo日志用来保证事务的原子性和MVCC,所有的undo操作产身的数据文件的变更也会记录到redo日志中。
在原生的MySQL中,redo日志不会用来做物理主从复制,其主要的应用场景是用来进行MySQL的Crash Recovey(崩溃恢复)。关于MySQL InnoDB的崩溃恢复会在后续的文章中进行介绍。
本文主要基于MySQL 8.0介绍redo Log的基本构成。
1. redo 日志文件
从MySQL 5.6开始,已经废弃了日志组的特性(redo日志可以写多份),网上有观点认为可能是InnoDB的开发团队认为用外层的存储硬件来保证日志组的完整性可能更好一些。同时从5.7开始InnoDB的归档日志Archive也被放弃(归档日志用来归档存放所有的redo日志,redo日志系统内是采用固定尺寸的多个log文件循环写的方式来存放redo日志,如果写满了会循环到开始的位置开始写入)。
不过MySQL 8.0引入一个称之为克隆的机制,从代码的角度来看,似乎是用来实现远程克隆一个当前数据库的副本,在这个机制中又引入的新的Archive归档机制。如果读者有兴趣可以阅读一下MySQL8.0新版本源码的storage\innobase\arch和 storage\innobase\clone目录下的代码。
1.1. redo Log相关参数
innodb_log_group_home_dir
该参数用来指定redo日志存放的路径,日志文件以ib_logfile[number]来命名。
innodb_log_files_in_group
虽然MySQL已经放弃了日志组的概念,但参数名依旧保留了下来以兼容以前的配置。该参数的含义为有多少个log文件(最少为2个)。
innodb_log_file_size
表示每个文件的大小。
所以,总的redo Log的大小为 innodb_log_files_in_group * innodb_log_file_size.

1.2. redo Log循环写
redo Log以顺序的方式写入文件,当全部文件写满的时候则回到第一个文件相应的起始位置进行覆盖写(但在做redo checkpoint时,也会更新第一个日志文件的头部checkpoint标记,所以严格来讲也不算顺序写),在InnoDB内部,逻辑上Redo Log被看作一个文件,对应一个space id (InnoDB通过space的概念来组织物理存储,包括不同的表,数据字典,redo,undo等)。
MySQL InnoDB redo Log 浅析

上图是以指定innodb_log_files_in_group为3的循环写的情况。

2. Redo Log存储格式简介
尽管Redo Log有多个文件,但每个文件的组成结构是一样的,只是有一些数据只会存在的第一个Log文件(ib_logfile0)的文件头中, 例如Buffer Pool flush checkpoint信息只会写在第一个log文件的文件头中。
2.1. 日志文件存储结构概览
MySQL InnoDB redo Log 浅析
(ib_logfile0 存储概览图)

MySQL InnoDB redo Log 浅析
(ib_logfile0 之外其它redo log文件的存储概览)
InnoDB也是采用WAL的机制来保证事务的持久性,从一定的意义上来说,redo日志是顺序写,写入速度很快。数据库事务导致的数据修改进入到InnoDB存储层之后会将这些修改变更的记录存入redo log中,然后将数据的变更写入内存中的Page Pool中。InnoDB的后台线程会按照一定的规则(例如定时或者脏页的数量达到一定的比例)将脏页落盘,落盘后会记录下来当前redo Log中有多少变更日志已经实际存储到了实际的数据space文件中。redo log的总的写入量叫LSN(Log Secquence Numer)日志序列号,这个redo log变更实际写入到实际数据文件中的数量叫checkpoint LSN,表示的是有多少变更已经实际写入到了相应的数据文件中。 一旦数据库崩溃InnoDB开始恢复数据的时候,先读取checkpoint,然后从checkpoint所指示的LSN读取其之后的Redo日志进行数据恢复,从而减少Crash Recovery的时间。
比较前面两个概览图可以看到,checkpoint信息只是存储在第一个log文件头中。同时我们看到日志头中有2个checkpoint block域。InnoDB是采用2个checkpoint了轮流写的方式来保证checkpoint的安全(并不是一次写2份checkpoint, 而是轮流写)。 也由于Redo log是幂等的,应用一次和与应用两次都是一样的(在实际的应用Redo中,如果当前这一条log的lsn大于当前page的lsn,说明这一条log还没有被应用到当前page中去)。所以,即使某次checkpoint block写失败了,那么崩溃恢复的时候从上一次记录的checkpoint点开始恢复也能正确的恢复数据库事务。
2.2. Log File Header
MySQL InnoDB redo Log 浅析
(Log File Header存储结构)
Log Header Format:
这个字段以前用来标识当前Log文件属于哪个日志组,现在新的意义是用来标识当前Log为文件的格式版本。例如如果为0则表示这个redo log是有5.7.9以前的MySQL生成的。
PAD:
没有任何含义,目前仅仅用来做一些对齐处理。
Start LSN:
这个字段用在Clone和Archive场景,与一般的持久性、崩溃恢复无关,这里不做讨论。
Creator:
存储的是创建这个log文件创建者的名称的字符串。
Left Bytes:
目前没有任何含义,仅仅是用来填充占位,以便让这个block达到512字节大小。
2.3. Log Checkpoint
MySQL InnoDB redo Log 浅析
(Checkpoint block储存概览)
checkpoint number:
checkpoint number可以理解为checkpoint域写盘的次数,每次写盘递增1,同时这个值取模2可以实现2个checkpoint域轮流写。
checkpoint LSN:
该字段标示小于这个Checkpoint LSN的日志记录都已经写入到了实际的数据文件中,Crash Recovery系统从Checkpoint LSN之后的第一个MTR记录开始进行数据恢复。
checkpoint offset:
Checkpoint LSN对应在Log files中的文件偏移量,这个用来对LSN和Offset之间转换进行校准。
Buf size:
MySQL系统内只对该字段执行了写入,并为进行读取然后进行相应的处理。它标识的是系统当前Log buffer的大小。
Left bytes:
目前没有任何含义,仅仅是用来填充占位,以便让这个block达到512字节大小。但在这里最后4个字节用来存放该checkpoint域的Checksum。

2.4. Log Block的存储格式
MySQL InnoDB redo Log 浅析
(Log Block的存储格式)
Log Block Number:
Log Block的编号,从1开始递增,达到最大值(0x3FFFFFFF+1)后再继续从1开始。
Data length:
写入到当前block的字节数,包含头部12字节的大小
Firsrt Record offset
本Block内第一个mtr记录的起始偏移量
log Block Checkpoint number
该block所处在的checkpoint no
Log Records:
一个block内可以存储多条mtr记录,同样一个mtr记录可以跨越多个block.
2.5. redo日志逻辑格式到物理格式的映射
MySQL InnoDB redo Log 浅析
上图是以指定innodb_log_files_in_group为2逻辑结构到物理结构的映射

上图中上层的为Redolog的逻辑结构,可以看作是内存中的log buffer, 下层的为redo Log的实际物理文件存储,由于版面的关系,我们以innodb_log_files_in_group为2来做示例,每个log文件中仅仅包含了2个log block(Log block的多少取决与设定的innodb_log_file_size)。
每产生一个mtr记录就将其append到log buffer中去,当log buffer落盘的时候会获取固定大小的数据写入到block的数据域。当然,如果buffer中剩余的数据不足以填满一个block的数据域,也会将其写入到一个新的block中,不足的数据自动不齐,block header中的data length字段会指出有效数据的数量。

2.6. MTR简介
MTR即Mini-transaction的缩写,字面意思小事物,相对逻辑事物而言,我们把它称作物理事物。属于Innodb存储引擎的底层模块。主要用于锁和日志信息。InnoDB内部的上层模块会将事务操作转换成若干的MTR物理事务。至于上层的事务操作如何转换的MTR此操作,后续再另外单独介绍,本文只介绍一下MTR记录的格式。
每一个MTR操作会产身一条MTR Record, 下一小节我们会介绍一下MTR记录的格式。
2.7. MTR记录格式
用一句通俗的话来讲,一条MTR记录表示的是对哪个数据文件(space id)的哪一页(page)的页内某个偏移量(offset)位置做了什么改变(value).
MySQL InnoDB redo Log 浅析

(一条MTR记录的通用格式)
Type:
MTR记录的类型
Space ID:
该MTR记录修改了哪个数据文件
Page Number
该MTR记录修改了哪一页
Record Payload:
根据Type的不同,Payload内容格式也不相同,大小也不相同。后面会给出一个Type为MLOG_COMP_REC_INSERT大致的存储结构。
(MTR Type - MLOG_COMP_REC_INSERT)
MySQL InnoDB redo Log 浅析
最后列出一些MTR Record Type, 读者从名字应该就能看出这个Type的含义
/ one byte is written */
MLOG_1BYTE = 1,
/* 2 bytes ... /
MLOG_2BYTES = 2,
/
4 bytes ... */
MLOG_4BYTES = 4,
/ 8 bytes ... */
MLOG_8BYTES = 8,
/* Record insert /
MLOG_REC_INSERT = 9,
/
Mark clustered index record deleted */
MLOG_REC_CLUST_DELETE_MARK = 10,
/ Mark secondary index record deleted */
MLOG_REC_SEC_DELETE_MARK = 11,
/* update of a record, preserves record field sizes /
MLOG_REC_UPDATE_IN_PLACE = 13,
/!< Delete a record from a page /
MLOG_REC_DELETE = 14,
/
Delete record list end on index page */
MLOG_LIST_END_DELETE = 15,
/ Delete record list start on index page */
MLOG_LIST_START_DELETE = 16,
/* Copy record list end to a new created index page /
MLOG_LIST_END_COPY_CREATED = 17,
/
Reorganize an index page in ROW_FORMAT=REDUNDANT */
MLOG_PAGE_REORGANIZE = 18,
/ Create an index page */
MLOG_PAGE_CREATE = 19,
/* mark a compact index record as the predefined minimum record /
MLOG_COMP_REC_MIN_MARK = 36,
/
create a compact index page */
MLOG_COMP_PAGE_CREATE = 37,
/* compact record insert /
MLOG_COMP_REC_INSERT = 38,
/* mark compact clustered index record deleted /
MLOG_COMP_REC_CLUST_DELETE_MARK = 39,

本文由京东商城数据库技术部王治提供。

### MySQL Redo Log 的工作原理及用途 #### 作用 MySQL 中的 Redo LogInnoDB 存储引擎中的核心组件之一,主要用于保障数据库事务的一致性和持久性。当数据库发生崩溃时,Redo Log 能够帮助恢复未完成的数据写入操作,从而确保事务不会因为意外中断而丢失[^2]。 具体来说,Redo Log 记录了所有对数据页所做的修改操作。这些记录可以用来重新执行(即重做)那些已经提交但尚未完全写入磁盘的操作。通过这种方式,即使系统在某个时间点突然宕机,重启后也能利用 Redo Log 将数据恢复到最新的状态[^1]。 --- #### 结构 Redo Log 的存储结构由两部分组成:**Log Buffer** 和 **Log File**。 1. **Log Buffer**: 这是一个位于内存中的缓冲区,在服务器启动时会预先分配一片连续的空间作为 redo log buffer。所有的日志写入操作都会优先写入这个缓冲区中,而不是直接写入磁盘上的文件。这样做的目的是为了减少频繁的随机 IO 操作,提升性能[^4]。 2. **Log File**: 当 Log Buffer 达到一定条件(例如满了或者满足特定的时间间隔),其内容会被刷入磁盘上的物理文件中。这部分文件通常被称为 redo log file 或者 ib_logfile* 文件。它们保存着实际的日志数据,并且具有循环覆盖的特点——也就是说,旧的日志会在不再需要的时候被新日志替换掉。 此外,还存在一个重要的参数 `innodb_flush_log_at_trx_commit`,它可以控制何时将 Log Buffer 刷入磁盘: - 如果设置为 0,则每秒刷新一次; - 设置为 1 表示每次事务提交都立即同步到磁盘; - 设置为 2 同样也是按需写回缓存,不过仅保证一秒内至少有一次真正的 fsync() 操作。 --- #### 配置方法 以下是几个常用的配置项及其含义: 1. **innodb_log_file_size** - 定义单个 redo log 文件的最大尺寸,默认情况下可能不足以应对高负载环境下的需求。 - 修改此值需要注意停服重建表空间的过程可能会比较耗时。 2. **innodb_log_files_in_group** - 控制一组中有多少个 redo log files 可供轮转使用。 3. **innodb_log_buffer_size** - 如前所述,这是指定了 Log Buffer 大小的一个变量,默认值一般设得较小(如 16 MB)。对于大事务场景下建议适当调增以降低磁盘压力。 4. **sync_binlog** - Binlog 的同步频率虽然不直接影响 Redo Log,但如果两者配合不当也可能引发一致性问题,因此也需要关注它的取值范围。 --- ```sql -- 查看当前 redo log 参数配置 SHOW VARIABLES LIKE 'innodb%log%'; SET GLOBAL innodb_flush_log_at_trx_commit = 1; -- 动态调整trx commit行为 ``` 上述 SQL 查询语句可以帮助管理员快速获取关于 redo log 的现有设定情况并作出相应优化决策。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值