快捷搜索:
来自 网络数据库 2019-11-06 06:44 的文章
当前位置: 67677新澳门手机版 > 网络数据库 > 正文

新京葡娱乐场网址:innodb源码解析之重做日志结

innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。

MySQL系列:innodb源码分析之重做日志结构

 

undo log不是redo log的逆向过程,其实它们都算是用来恢复的日志:
1.redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。
2.undo用来回滚行记录到某个版本。undo log一般是逻辑日志,根据每行记录进行记录。

1.LSN

在innodb中的重做日志系统中,定义一个LSN序号,其代表的意思是日志序号。LSN在引擎中定义的是一个dulint_t类型值,相当于uint64_t,关于dulint_t的定义如下:

 

 

typedef struct dulint_struct
{
     ulint high;     /* most significant 32 bits */
     ulint low;       /* least significant 32 bits */
}dulint_t;

LSN真正的含义是储存引擎向重做日志系统写入的日志量(字节数),这个日志量包括写入的日志字节

  • block_header_size block_tailer_size。LSN的初始化值是:LOG_START_LSN(相当于8192),在调用日志写入函数LSN就一直随着写入的日志长度增加,具体看:

 

 

void log_write_low(byte* str, ulint str_len)
{
 log_t* log = log_sys;
. . .
part_loop:
 /*计算part length*/
 data_len = log->buf_free % OS_FILE_LOG_BLOCK_SIZE   str_len;
.  .  . 
 /*将日志内容拷贝到log buffer*/
 ut_memcpy(log->buf   log->buf_free, str, len);
 str_len -= len;
 str = str   len;
 . . .
 if(data_len = OS_FILE_LOG_BLOCK_SIZE - LOG_BLOCK_TRL_SIZE){ /*完成一个block的写入*/
. . .
      len  = LOG_BLOCK_HDR_SIZE   LOG_BLOCK_TRL_SIZE;
      log->lsn = ut_dulint_add(log->lsn, len);
 . . .
 }
 else /*更改lsn*/
  log->lsn = ut_dulint_add(log->lsn, len);
 . . .
}

 

LSN是不会减小的,它是日志位置的唯一标记。在重做日志写入、checkpoint构建和PAGE头里面都有LSN。

关于日志写入:

例如当前重做日志的LSN = 2048,这时候innodb调用log_write_low写入一个长度为700的日志,2048刚好是4个block长度,那么需要存储700长度的日志,需要量个BLOCK(单个block只能存496个字节)。那么很容易得出新的LSN = 2048 700 2 * LOG_BLOCK_HDR_SIZE(12) LOG_BLOCK_TRL_SIZE(4) = 2776。

关于checkpoint和日志恢复:

在page的fil_header中的LSN是表示最后刷新是的LSN, 假如数据库中存在PAGE1 LSN = 1024,PAGE2 LSN = 2048, 系统重启时,检测到最后的checkpoint LSN = 1024,那么系统在检测到PAGE1不会对PAGE1进行恢复重做,当系统检测到PAGE2的时候,会将PAGE2进行重做。一次类推,小于checkpoint LSN的页不用重做,大于LSN checkpoint的PAGE就要进行重做。

1.redo log

2.Log Block

innodb在日志系统里面定义了log block的概念,其实log block就是一个512字节的数据块,这个数据块包括块头、日志信息和块的checksum.其结构如下:

新京葡娱乐场网址 1

Block no的最高位是描述block是否flush磁盘的标识位.通过lsn可以blockno,具体的计算过程是lsn是多少个512的整数倍,也就是no = lsn / 512 1;为什么要加1呢,因为所处no的块算成clac_lsn一定会小于传入的lsn.所以要 1。其实就是block的数组索引值。checksum是通过从块头开始到块的末尾前4个字节为止,做了一次数字叠加,代码如下:

sum = 1;
 sh = 0;
 for(i = 0; i < OS_FILE_LOG_BLOCK_SIZE - LOG_BLOCK_TRL_SIZE, i   ){
      sum = sum & 0x7FFFFFFF;
      sum  = (((ulint)(*(block   i))) << sh)   (ulint)(*(block   i));
      sh   ;
      if(sh > 24) 
        sh = 0;
 }

在日志恢复的时候,innodb会对加载的block进行checksum校验,以免在恢复过程中数据产生错误。事务的日志写入是基于块的,如果事务的日志大小小于496字节,那么会合其他的事务日志合并在一个块中,如果事务日志的大小大于496字节,那么会以496为长度进行分离存储。例如:T1 = 700字节大小,T2 = 100字节大小存储结构如下:

 

新京葡娱乐场网址 2

 

1.1 redo log和二进制日志的区别

二进制日志相关内容,参考:MariaDB/MySQL的二进制日志。

redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作,也能实现重做的功能,但是它们之间有很大区别。

  1. 二进制日志是在存储引擎的上层产生的,不管是什么存储引擎,对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的,只记录该存储引擎中表的修改。并且二进制日志先于redo log被记录。具体的见后文group commit小结。
  2. 二进制日志记录操作的方法是逻辑性的语句。即便它是基于行格式的记录方式,其本质也还是逻辑的SQL设置,如该行记录的每列的值是多少。而redo log是在物理格式上的日志,它记录的是数据库中每个页的修改。
  3. 二进制日志只在每次事务提交的时候一次性写入缓存中的日志"文件"。而redo log在数据准备修改前写入缓存中的redo log中,然后才对缓存中的数据执行修改操作;而且保证在发出事务提交指令时,先向缓存中的redo log写入日志,写入完成后才执行提交动作。
  4. 因为二进制日志只在提交的时候一次性写入,所以二进制日志中的记录方式和提交顺序有关,且一次提交对应一次记录。而redo log中是记录的物理页的修改,redo log文件中同一个事务可能多次记录,最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1,可能在redo log中记录了 T1-1,T1-2,T1-3,T1* 共4个操作,其中 T1* 表示最后提交时的日志记录,所以对应的数据页最终状态是 T1* 对应的操作结果。而且redo log是并发写入的,不同事务之间的不同版本的记录会穿插写入到redo log文件中,例如可能redo log的记录方式如下: T1-1,T1-2,T2-1,T2-2,T2*,T1-3,T1* 。
  5. 事务日志记录的是物理页的情况,它具有幂等性,因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的,例如新插入一行后又删除该行,前后状态没有变化。而二进制日志记录的是所有影响数据的操作,记录的内容较多。例如插入一行记录一次,删除该行又记录一次。

3.重做日志结构和关系图

innodb在重做日志实现当中,设计了3个层模块,即redo log buffer、group files和archive files。这三个层模块的描述如下:

 

 

redo log buffer 重做日志的日志内存缓冲区,新写入的日志都是先写入到这个地方.redo log buffer中数据同步到磁盘上,必须进行刷盘操作。

group files 重做日志文件组,一般由3个同样大小的文件组成。3个文件的写入是依次循环的,每个日志文件写满后,即写下一个,日志文件如果都写满时,会覆盖第一次重新写。重做日志组在innodb的设计上支持多个。

archive files 归档日志文件,是对重做日志文件做增量备份,它是不会覆盖以前的日志信息。

以下是它们关系示意图:
新京葡娱乐场网址 3

1.2 redo log的基本概念

redo log包括两部分:一是内存中的日志缓冲(redo log buffer),该部分日志是易失性的;二是磁盘上的重做日志文件(redo log file),该部分日志是持久的。

在概念上,innodb通过force log at commit机制实现事务的持久性,即在事务提交的时候,必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。

为了确保每次日志都能写入到事务日志文件中,在每次将log buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MariaDB/MySQL是工作在用户空间的,MariaDB/MySQL的log buffer处于用户空间的内存中。要写入到磁盘上的log file中(redo:ib_logfileN文件,undo:share tablespace或.ibd文件),中间还要经过操作系统内核空间的os buffer,调用fsync()的作用就是将OS buffer中的日志刷到磁盘上的log file中。

也就是说,从redo log buffer写日志到磁盘的redo log file中,过程如下: 

新京葡娱乐场网址 4

在此处需要注意一点,一般所说的log file并不是磁盘上的物理日志文件,而是操作系统缓存中的log file,官方手册上的意思也是如此(例如:With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and style="color: #ff0000;">the log file is flushed to disk approximately once per second)。但说实话,这不太好理解,既然都称为file了,应该已经属于物理文件了。所以在本文后续内容中都以os buffer或者file system buffer来表示官方手册中所说的Log file,然后log file则表示磁盘上的物理日志文件,即log file on disk。

MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值:0、1、2,默认为1。但注意,这个变量只是控制commit动作是否刷新log buffer到磁盘。

  • 当设置为1的时候,事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO的性能较差。
  • 当设置为0的时候,事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。
  • 当设置为2的时候,每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

新京葡娱乐场网址 5

注意,有一个变量 innodb_flush_log_at_timeout 的值为1秒,该变量表示的是刷日志的频率,很多人误以为是控制 innodb_flush_log_at_trx_commit 值为0和2时的1秒频率,实际上并非如此。测试时将频率设置为5和设置为1,当 innodb_flush_log_at_trx_commit 设置为0和2的时候性能基本都是不变的。关于这个频率是控制什么的,在后面的"刷日志到磁盘的规则"中会说。

在主从复制结构中,要保证事务的持久性和一致性,需要对日志相关变量设置为如下:

  • 如果启用了二进制日志,则设置sync_binlog=1,即每提交一次事务同步写到磁盘中。
  • 总是设置innodb_flush_log_at_trx_commit=1,即每提交一次事务都写到磁盘中。

上述两项变量的设置保证了:每次提交事务都写入二进制日志和事务日志,并在提交时将它们刷新到磁盘中。

选择刷日志的时间会严重影响数据修改时的性能,特别是刷到磁盘的过程。下例就测试了 innodb_flush_log_at_trx_commit 分别为0、1、2时的差距。

#创建测试表
drop table if exists test_flush_log;
create table test_flush_log(id int,name char(50))engine=innodb;

#创建插入指定行数的记录到测试表中的存储过程
drop procedure if exists proc;
delimiter $$
create procedure proc(i int)
begin
    declare s int default 1;
    declare c char(50) default repeat('a',50);
    while s<=i do
        start transaction;
        insert into test_flush_log values(null,c);
        commit;
        set s=s 1;
    end while;
end$$
delimiter ;

当前环境下, innodb_flush_log_at_trx_commit 的值为1,即每次提交都刷日志到磁盘。测试此时插入10W条记录的时间。

mysql> call proc(100000);
Query OK, 0 rows affected (15.48 sec)

结果是15.48秒。

再测试值为2的时候,即每次提交都刷新到os buffer,但每秒才刷入磁盘中。

mysql> set @@global.innodb_flush_log_at_trx_commit=2;    
mysql> truncate test_flush_log;

mysql> call proc(100000);
Query OK, 0 rows affected (3.41 sec)

结果插入时间大减,只需3.41秒。

最后测试值为0的时候,即每秒才刷到os buffer和磁盘。

mysql> set @@global.innodb_flush_log_at_trx_commit=0;
mysql> truncate test_flush_log;

mysql> call proc(100000);
Query OK, 0 rows affected (2.10 sec)

结果只有2.10秒。

最后可以发现,其实值为2和0的时候,它们的差距并不太大,但2却比0要安全的多。它们都是每秒从os buffer刷到磁盘,它们之间的时间差体现在log buffer刷到os buffer上。因为将log buffer中的日志刷新到os buffer只是内存数据的转移,并没有太大的开销,所以每次提交和每秒刷入差距并不大。可以测试插入更多的数据来比较,以下是插入100W行数据的情况。从结果可见,值为2和0的时候差距并不大,但值为1的性能却差太多。

新京葡娱乐场网址 6

尽管设置为0和2可以大幅度提升插入性能,但是在故障的时候可能会丢失1秒钟数据,这1秒钟很可能有大量的数据,从上面的测试结果看,100W条记录也只消耗了20多秒,1秒钟大约有4W-5W条数据,尽管上述插入的数据简单,但却说明了数据丢失的大量性。更好的插入数据的做法是将值设置为1,然后修改存储过程,将每次循环都提交修改为只提交一次**,**这样既能保证数据的一致性,也能提升性能,修改如下:

drop procedure if exists proc;
delimiter $$
create procedure proc(i int)
begin
    declare s int default 1;
    declare c char(50) default repeat('a',50);
    start transaction;
    while s<=i DO
        insert into test_flush_log values(null,c);
        set s=s 1;
    end while;
    commit;
end$$
delimiter ;

测试值为1时的情况。

mysql> set @@global.innodb_flush_log_at_trx_commit=1;
mysql> truncate test_flush_log;

mysql> call proc(1000000);
Query OK, 0 rows affected (11.26 sec)

 

1.3 日志块(log block)

innodb存储引擎中,redo log以块为单位进行存储的,每个块占512字节,这称为redo log block。所以不管是log buffer中还是os buffer中以及redo log file on disk中,都是这样以512字节的块存储的。

每个redo log block由3部分组成:日志块头、日志块尾和日志主体。其中日志块头占用12字节,日志块尾占用8字节,所以每个redo log block的日志主体部分只有512-12-8=492字节。

新京葡娱乐场网址 7

因为redo log记录的是数据页的变化,当一个数据页产生的变化需要使用超过492字节()的redo log来记录,那么就会使用多个redo log block来记录该数据页的变化。

日志块头包含4部分:

  • Ÿ log_block_hdr_no:(4字节)该日志块在redo log buffer中的位置ID。
  • Ÿ log_block_hdr_data_len:(2字节)该log block中已记录的log大小。写满该log block时为0x200,表示512字节。
  • Ÿ log_block_first_rec_group:(2字节)该log block中第一个log的开始偏移位置。
  • Ÿ lock_block_checkpoint_no:(4字节)写入检查点信息的位置。

关于log block块头的第三部分 log_block_first_rec_group ,因为有时候一个数据页产生的日志量超出了一个日志块,这是需要用多个日志块来记录该页的相关日志。例如,某一数据页产生了552字节的日志量,那么需要占用两个日志块,第一个日志块占用492字节,第二个日志块需要占用60个字节,那么对于第二个日志块来说,它的第一个log的开始位置就是73字节(60 12)。如果该部分的值和 log_block_hdr_data_len 相等,则说明该log block中没有新开始的日志块,即表示该日志块用来延续前一个日志块。

日志尾只有一个部分: log_block_trl_no ,该值和块头的 log_block_hdr_no 相等。

上面所说的是一个日志块的内容,在redo log buffer或者redo log file on disk中,由很多log block组成。如下图:

新京葡娱乐场网址 8

3.1重做日志组

重做日志组可以支持多个,这样做的目的应该是为了防止一个日志组损坏后,可以从其他并行的日志组里面进行数据恢复。在MySQL-5.6的将日志组的个数设置为1,不允许多个group存在。网易姜承尧的解释是innodb的作者认为通过外层存储硬件来保证日志组的完整性比较好,例如raid磁盘。重做日志组的主要功能是实现对组内文件的写入管理、组内的checkpoint建立和checkpiont信息的保存、归档日志状态管理(只有第一个group才做archive操作).以下是对日志组的定义:

 

typedef struct log_group_struct
{
 ulint id;                             /*log group id*/
 ulint n_files;                      /*group包含的日志文件个数*/
 ulint file_size;                   /*日志文件大小,包括文件头*/
 ulint space_id;                  /*group对应的fil_space的id*/
 ulint state;                        /*log group状态,LOG_GROUP_OK、LOG_GROUP_CORRUPTED*/
 dulint lsn;                         /*log group的lsn*/
 dulint lsn_offset;              /*当前lsn相对组内文件起始位置的偏移量 */
 ulint n_pending_writes;   /*本group 正在执行fil_flush的个数*/
 byte** file_header_bufs;  /*文件头缓冲区*/
 byte** archive_file_header_bufs;/*归档文件头信息的缓冲区*/
 ulint archive_space_id;      /*归档重做日志ID*/
 ulint archived_file_no;      /*归档的日志文件编号*/
 ulint archived_offset;      /*已经完成归档的偏移量*/
 ulint next_archived_file_no; /*下一个归档的文件编号*/
 ulint next_archived_offset; /*下一个归档的偏移量*/
 dulint scanned_lsn;
 byte* checkpoint_buf;   /*本log group保存checkpoint信息的缓冲区*/
 UT_LIST_NODE_T(log_group_t) log_groups;
}log_group_t;

 

上面结构定义中的spaceid是对应fil0fil中的fil_space_t结构,一个fil_space_t结构可以管理多个文件fil_node_t,关于fil_node_t参见这里。

1.4 log group和redo log file

log group表示的是redo log group,一个组内由多个大小完全相同的redo log file组成。组内redo log file的数量由变量 innodb_log_files_group 决定,默认值为2,即两个redo log file。这个组是一个逻辑的概念,并没有真正的文件来表示这是一个组,但是可以通过变量 innodb_log_group_home_dir 来定义组的目录,redo log file都放在这个目录下,默认是在datadir下。

mysql> show global variables like "innodb_log%";
 ----------------------------- ---------- 
| Variable_name               | Value    |
 ----------------------------- ---------- 
| innodb_log_buffer_size      | 8388608  |
| innodb_log_compressed_pages | ON       |
| innodb_log_file_size        | 50331648 |
| innodb_log_files_in_group   | 2        |
| innodb_log_group_home_dir   | ./       |
 ----------------------------- ---------- 

[root@xuexi data]# ll /mydata/data/ib*
-rw-rw---- 1 mysql mysql 79691776 Mar 30 23:12 /mydata/data/ibdata1
-rw-rw---- 1 mysql mysql 50331648 Mar 30 23:12 /mydata/data/ib_logfile0
-rw-rw---- 1 mysql mysql 50331648 Mar 30 23:12 /mydata/data/ib_logfile1

可以看到在默认的数据目录下,有两个ib_logfile开头的文件,它们就是log group中的redo log file,而且它们的大小完全一致且等于变量 innodb_log_file_size 定义的值。第一个文件ibdata1是在没有开启 innodb_file_per_table 时的共享表空间文件,对应于开启 innodb_file_per_table 时的.ibd文件。

在innodb将log buffer中的redo log block刷到这些log file中时,会以追加写入的方式循环轮训写入。即先在第一个log file(即ib_logfile0)的尾部追加写,直到满了之后向第二个log file(即ib_logfile1)写。当第二个log file满了会清空一部分第一个log file继续写入。

由于是将log buffer中的日志刷到log file,所以在log file中记录日志的方式也是log block的方式。

在每个组的第一个redo log file中,前2KB记录4个特定的部分,从2KB之后才开始记录log block。除了第一个redo log file中会记录,log group中的其他log file不会记录这2KB,但是却会腾出这2KB的空间。如下:

新京葡娱乐场网址 9

redo log file的大小对innodb的性能影响非常大,设置的太大,恢复的时候就会时间较长,设置的太小,就会导致在写redo log的时候循环切换redo log file。

3.1.1LSN与组内偏移

在log_goup_t组内日志模块当中,其中比较重要的是关于LSN与组内偏移之间的换算关系。在组创建时,会对lsn和对应lsn_offset做设置,假如 初始化为 group lsn = 1024, group lsn_offset = 2048,group由3个10240大小的文件组成,LOG_FILE_HDR_SIZE = 2048, 我们需要知道buf lsn = 11240对应的组内offset的偏移是多少,根据log_group_calc_lsn_offset函数可以得出如下公式:
group_size = 3 * 11240;
相对组起始位置的LSN偏移 = (buf_ls - group_ls) log_group_calc_size_offset(lsn_offset ) = (11240 - 1024) - 0 = 10216;
lsn_offset = log_group_calc_lsn_offset(相对组起始位置的LSN偏移 % group_size) = 10216 2 * LOG_FILE_HDR_SIZE = 14312;
这个偏移一定是加上了文件头长度的。

 

1.5 redo log的格式

因为innodb存储引擎存储数据的单元是页(和SQL Server中一样),所以redo log也是基于页的格式来记录的。默认情况下,innodb的页大小是16KB(由 innodb_page_size 变量控制),一个页内可以存放非常多的log block(每个512字节),而log block中记录的又是数据页的变化。

其中log block中492字节的部分是log body,该log body的格式分为4部分:

  • redo_log_type:占用1个字节,表示redo log的日志类型。
  • space:表示表空间的ID,采用压缩的方式后,占用的空间可能小于4字节。
  • page_no:表示页的偏移量,同样是压缩过的。
  • Ÿredo_log_body表示每个重做日志的数据部分,恢复时会调用相应的函数进行解析。例如insert语句和delete语句写入redo log的内容是不一样的。

如下图,分别是insert和delete大致的记录方式。

新京葡娱乐场网址 10

3.1.2 file_header_bufs

 

file_header_bufs是一个buffer缓冲区数组,数组长度和组内文件数是一致的,每个buf长度是2048。其信息结构如下:

新京葡娱乐场网址 11

 

log_group_id 对应log_group_t结构中的id

file_start_lsn 当前文件其实位置数据对应的LSN值

File_no 当前的文件编号,一般在archive file头中体现

Hot backup str 一个空字符串,如果是hot_backup,会填上文件后缀ibackup。

File_end_ls 文件结尾数据对应的LSN值,一般在archive file文件中体现。

1.6 日志刷盘的规则

log buffer中未刷到磁盘的日志称为脏日志(dirty log)。

在上面的说过,默认情况下事务每次提交的时候都会刷事务日志到磁盘中,这是因为变量 innodb_flush_log_at_trx_commit 的值为1。但是innodb不仅仅只会在有commit动作后才会刷日志到磁盘,这只是innodb存储引擎刷日志的规则之一。

刷日志到磁盘有以下几种规则:

1.发出commit动作时。已经说明过,commit发出后是否刷日志由变量 innodb_flush_log_at_trx_commit 控制。

2.每秒刷一次。这个刷日志的频率由变量 innodb_flush_log_at_timeout 值决定,默认是1秒。要注意,这个刷日志频率和commit动作无关。

3.当log buffer中已经使用的内存超过一半时。

4.当有checkpoint时,checkpoint在一定程度上代表了刷到磁盘时日志所处的LSN位置。

3.2 checkpoint

checkpoint是日志的检查点,其作用就是在数据库异常后,redo log是从这个点的信息获取到LSN,并对检查点以后的日志和PAGE做重做恢复。那么检查点是怎么生成的呢?当日志缓冲区写入的日志LSN距离上一次生成检查点的LSN达到一定差距的时候,就会开始创建检查点,创建检查点首先会将内存中的表的脏数据写入到硬盘,让后再将redo log buffer中小于本次检查点的LSN的日志也写入硬盘。在log_group_t中的checkpoint_buf,以下是它对应字段的解释:

LOG_CHECKPOINT_NO checkpoint序号,

LOG_CHECKPOINT_LSN 本次checkpoint起始的LSN

LOG_CHECKPOINT_OFFSET 本次checkpoint相对group file的起始偏移量

LOG_CHECKPOINT_LOG_BUF_SIZE redo log buffer的大小,默认2M

LOG_CHECKPOINT_ARCHIVED_LSN 当前日志归档的LSN

LOG_CHECKPOINT_GROUP_ARRAY 每个log group归档时的文件序号和偏移量,是一个数组

1.7 数据页刷盘的规则及checkpoint

内存中(buffer pool)未刷到磁盘的数据称为脏数据(dirty data)。由于数据和日志都以页的形式存在,所以脏页表示脏数据和脏日志。

上一节介绍了日志是何时刷到磁盘的,不仅仅是日志需要刷盘,脏数据页也一样需要刷盘。

在innodb中,数据刷盘的规则只有一个:checkpoint。但是触发checkpoint的情况却有几种。不管怎样,checkpoint触发后,会将buffer中脏数据页和脏日志页都刷到磁盘。

innodb存储引擎中checkpoint分为两种:

  • sharp checkpoint:在重用redo log文件(例如切换日志文件)的时候,将所有已记录到redo log中对应的脏数据刷到磁盘。
  • fuzzy checkpoint:一次只刷一小部分的日志到磁盘,而非将所有脏日志刷盘。有以下几种情况会触发该检查点:
    • master thread checkpoint:由master线程控制,每秒或每10秒刷入一定比例的脏页到磁盘。
    • flush_lru_list checkpoint:从MySQL5.6开始可通过 innodb_page_cleaners 变量指定专门负责脏页刷盘的page cleaner线程的个数,该线程的目的是为了保证lru列表有可用的空闲页。
    • async/sync flush checkpoint:同步刷盘还是异步刷盘。例如还有非常多的脏页没刷到磁盘(非常多是多少,有比例控制),这时候会选择同步刷到磁盘,但这很少出现;如果脏页不是很多,可以选择异步刷到磁盘,如果脏页很少,可以暂时不刷脏页到磁盘
    • dirty page too much checkpoint:脏页太多时强制触发检查点,目的是为了保证缓存有足够的空闲空间。too much的比例由变量 innodb_max_dirty_pages_pct 控制,MySQL 5.6默认的值为75,即当脏页占缓冲池的百分之75后,就强制刷一部分脏页到磁盘。

由于刷脏页需要一定的时间来完成,所以记录检查点的位置是在每次刷盘结束之后才在redo log中标记的。

MySQL停止时是否将脏数据和脏日志刷入磁盘,由变量innodb_fast_shutdown={ 0|1|2 }控制,默认值为1,即停止时忽略所有flush操作,在下次启动的时候再flush,实现fast shutdown。

3.3 log_t

重做日志的写入、数据刷盘、建立checkpoint和归档操作都是通过全局唯一的,log_sys进行控制的,这是个非常庞大而又复杂的结构,定义如下:

typedef struct log_struct
{
 byte pad[64];                     /*使得log_struct对象可以放在通用的cache line中的数据,这个和CPU L1 Cache和数据竞争有和
直接关系*/
 dulint lsn;                     /*log的序列号,实际上是一个日志文件偏移量*/
 ulint buf_free;              /*buf可以写的位置*/

 mutex_t mutex;           /*log保护的mutex*/
 byte* buf;                    /*log缓冲区*/
 ulint buf_size;              /*log缓冲区长度*/
 ulint max_buf_free;       /*在log buffer刷盘后,推荐buf_free的最大值,超过这个值会被强制刷盘*/

 ulint old_buf_free;         /*上次写时buf_free的值,用于调试*/
 dulint old_lsn;              /*上次写时的lsn,用于调试*/
 ibool check_flush_or_checkpoint; /*需要日志写盘或者是需要刷新一个log checkpoint的标识*/
 ulint buf_next_to_write;             /*下一次开始写入磁盘的buf偏移位置*/
 dulint written_to_some_lsn;         /*第一个group刷完成是的lsn*/
 dulint written_to_all_lsn;             /*已经记录在日志文件中的lsn*/
 dulint flush_lsn;                       /*flush的lsn*/
 ulint flush_end_offset;               /*最后一次log file刷盘时的buf_free,也就是最后一次flush的末尾偏移量*/
 ulint n_pending_writes;              /*正在调用fil_flush的个数*/
 os_event_t no_flush_event;          /*所有fil_flush完成后才会触发这个信号,等待所有的goups刷盘完成*/ 
 ibool one_flushed;                   /*一个log group被刷盘后这个值会设置成TRUE*/
 os_event_t one_flushed_event;     /*只要有一个group flush完成就会触发这个信号*/
 ulint n_log_ios;                        /*log系统的io操作次数*/
 ulint n_log_ios_old;                   /*上一次统计时的io操作次数*/
 time_t last_printout_time;
 ulint max_modified_age_async;     /*异步日志文件刷盘的阈值*/
 ulint max_modified_age_sync;       /*同步日志文件刷盘的阈值*/
 ulint adm_checkpoint_interval;
 ulint max_checkpoint_age_async;    /*异步建立checkpoint的阈值*/
 ulint max_checkpoint_age;            /*强制建立checkpoint的阈值*/
 dulint next_checkpoint_no;
 dulint last_checkpoint_lsn;
 dulint next_checkpoint_lsn;
 ulint n_pending_checkpoint_writes;
 rw_lock_t checkpoint_lock;            /*checkpoint的rw_lock_t,在checkpoint的时候,是独占这个latch*/
 byte* checkpoint_buf;                 /*checkpoint信息存储的buf*/
 ulint archiving_state;
 dulint archived_lsn;
 dulint max_archived_lsn_age_async;
 dulint max_archived_lsn_age;
 dulint next_archived_lsn;
 ulint archiving_phase;
 ulint n_pending_archive_ios;
 rw_lock_t archive_lock;
 ulint archive_buf_size;
 byte* archive_buf;
 os_event_t archiving_on;
 ibool online_backup_state;             /*是否在backup*/
 dulint online_backup_lsn;                /*backup时的lsn*/
 UT_LIST_BASE_NODE_T(log_group_t) log_groups;
}log_t;

本文由67677新澳门手机版发布于网络数据库,转载请注明出处:新京葡娱乐场网址:innodb源码解析之重做日志结

关键词: