导读

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

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

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物理结构

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

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

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

Log File Header Block

• 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

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

没错，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等，其头部格式如下所示

一条完整的INSERT redo record

关于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)