从物理文件理解InnoDB Redo Log

发布时间:2020-05-18 浏览次数:254

导读

作为MySQL DBA都应该知道,Redo Log是可被覆盖的,是ACID中的D的最重要的构成部分,也就是关系型数据库中的WAL中的L。

Redo Log记录的是redo,那么redo是什么呢?通俗来讲,redo记录的是对应的记录改变的物理操作。说实话,过去的很长一段时间内,我对redo的认识也仅限于此,并没有好好深入理解redo记录的到底是什么。这次从redo的物理结构上深入理解下redo到底是什么。

Redo Log逻辑&物理结构

从物理文件理解InnoDB Redo Log-爱可生


从逻辑上来讲,redo log记录是连续递增的,但是对应到物理文件就不一样了,考虑到磁盘空间,redo log被设计成了多个可循环写入的文件。InnoDB要求Redo Log,文件至少有2个,初始文件为 ib_logfile0和 ib_logfile1, ib_logfile0写完以后写 ib_logfile1,等到 ib_logfile1也写完了,从头又开始写 ib_logfile0,这样就形成了一个环形写入的结构。但是覆盖写入的前提是要确定哪个位置点是可以覆盖写的,哪些位置是不能覆盖写的,这个就是check point的工作了,关于checkpoint可以关注我上一篇文章《MySQL Checkpoint》。

Log File物理结构

从物理文件理解InnoDB Redo Log-爱可生


从物理文件理解InnoDB Redo Log-爱可生


从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出,在Log Header部分还是有些许差异的, ib_logfile0会多一些额外的信息,主要是checkpoint信息。

并且每个Block的单位是512字节,对应到磁盘每个扇区也是512字节,因此redo log写磁盘是原子写,保证能够写成功,而不像index page一样需要double write来保证安全写入。

我们依次从上到下来看每个Block的结构

Log File Header Block

从物理文件理解InnoDB Redo Log-爱可生


  • Log Goup ID,可能会配置多个redo组,每个组对应一个id,当前都是0,占用4字节

  • Start LSN,这个redo log文件开始日志的lsn,占用8字节

  • Log File Number,总是为0,占用4字节

  • Created By,备份程序所占用的字节数,占用32字节

另外在ib_logfile0中会有两个checkpoint block,分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2,两个记录InnoDB Checkpoint信息的字段,分别从文件头的第二个和第四个block开始记录,并且只在每组log的第一个文件中存在,组内其他文件虽然没有checkpoint相关信息,但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢?原因是设计为交替写入,避免因为介质失败而导致无法找到可用的checkpoint的情况。

Log blocks

从物理文件理解InnoDB Redo Log-爱可生


log block结构分为日志头段、日志记录、日志尾部

  • Block Header,占用12字节

  • Data部分

  • Block tailer,占用4字节

Block Header

这个部分是每个Block的头部,主要记录的块的信息

  • Block Number,表示这是第几个block,占用4字节,是通过LSN计算得来的,占用4字节

  • Block data len,表示该block中有多少字节已经被使用了,占用2字节

  • First Rec offet,表示该block中作为第一个新的mtr开始的偏移量,占用2字节

  • Checkpoint number,表示该log block最后被写入时的检查点的值,占用4字节

Data部分

这部分才开始真正记录我们理解的redo log,实际真正可用字节数为512-12-4=496字节,用户的redo是以一条一条的记录存放在这个block的data部分,并且一条redo记录可能会占用多个block

Block tailfer

tailer部分就比较简单了,只是记录一个checksum值,用于正确性校验,占用4字节

Log Record

从物理文件理解InnoDB Redo Log-爱可生


从物理文件理解InnoDB Redo Log-爱可生


没错,redo记录就是这个结构,分为头部、body部分

通用header

  • redo_log_type,重做日志的类型

  • space ID,表空间ID

  • Page Numer,用于定位哪个page

redo包括几种类型,M_LOG_WRITE_1BYTE、M_LOG_WRITE_2BYTE、M_LOG_WRITE_4BYTE和M_LOG_WRITE_STRING等,其头部格式如下所示

从物理文件理解InnoDB Redo Log-爱可生


从物理文件理解InnoDB Redo Log-爱可生



一条完整的INSERT redo record

从物理文件理解InnoDB Redo Log-爱可生


关于LSN

LSN几乎是redo中最重要的概念之一了,LSN表示redo的写入量,标识了checkpoint的位置,标识了page的版本。LSN不仅存在与redo log中,还存在于每个page中。在每个page的头部,有一个 FIL_PAGE_LSN,记录了page的LSN,表示该页最后刷新时的LSN大小。redo中记录的是每个page的日志,因此page中的LSN用来判断是否需要进行恢复操作,这对于MySQL的崩溃恢复及其重要。

关于redo刷盘机制

大概有以下几种情况会触发redo log刷盘

  1. log buffer空间用完了,这就会将已经产生的log buffer中的日志刷到磁盘中,这是最普遍的一种方式;

  2. master线程在后台每秒钟刷一次,将当前log buffer中的日志刷到磁盘中;

  3. 每次执行DML操作时,都会主动检查日志空间是否足够,如果使用空间的量已经超过了一个预设的经验值,就会主动刷日志,以保证在后面真正执行时,不会再执行过程中被动的刷盘,但这里只会是写文件(写入OS缓冲中)不会刷盘

  4. 在做checkpoint的时候,要保证所有要刷的页面中LSN值最小的日志已经刷入到磁盘,不然,如果此时数据库宕机,日志不存在,但数据页面已经被修改,从而导致数据不一致,就违背了写日志的原则;

  5. 提交逻辑事务时,会因为参数 innodb_flush_log_at_trx_commit值的不同,产生不同的行为。如果设置0,则在事务提交时,不会去刷日志缓冲区,等待master thread以固定频率去刷盘,这种设置是最危险的 如果设置2,则在事务提交时会将日志写入到文件中,但不会去刷盘,只要操作系统不挂,即使数据库挂了,数据还是不会丢失 如果设置1,则在事务提交的时候将日志写入文件同时fsync,保证redo log落盘,生产环境主库强烈建议设置为1

几个建议:

  1. innodb_flush_log_at_trx_commit设置为1

  2. redo log建议设置2G,组数建议为3组以上,避免因为redo log切换导致性能抖动

  3. redo log buffer建议设置32M以上(根据实际情况至少能够缓存1秒的redo)

上一篇: 教你如何使用UE观察InnoDB Page结构

下一篇: MySQL 数据类型的艺术

产品试用 产品试用
400-820-6580 免费电话