InnoDB学习（四）之RedoLog和UndoLog

BinLog是MySQL Server层的日志，所有的MySQL存储引擎都支持BinLog。BinLog可以支持主从复制和数据恢复，但是对事务的ACID特性支持比较差。InnoDB存储引擎引入RedoLog和UndoLog事务日志，用于提升事务场景下的数据库性能。本文会对RedoLog和UndoLog进行介绍。

RedoLog和UndoLog

ChangeBuffer和WAL

我们以一条SQL更新语句来介绍RedoLog的作用，首先在数据库中创建user_info表，该表包含主键列id和姓名列，并向数据库中插入一列测试数据：

create table user_info
(
    id int primary key,
    name  varchar(255)
);

insert into user_info(id,name) value (1,'ls');

查询语句的执行流程

如果我们需要查询id=1的用户的信息，我们可以通过以下SQL语句进行查询：

select  * from user_info where id = 1;

在这一条简单的查询语句之后，MySQL做了哪些工作呢？如下所示，MySQL执行SQL查询语句的流程包含以下步骤：

  1. 连接器：客户端和MySQL服务端建立连接，用户名密码等信息校验；
  2. 查询缓存：如果SQL语句是查询语句，则查看查询语句是否命中缓存；
  3. 分析器：对SQL语句的词法和语法进行分析，判断SQL语句的类型和对应的表等信息；
  4. 优化器：对SQL语句进行优化，选择合适的索引；
  5. 执行器：在对应的MySQL引擎上执行SQL查询语句，并返回查询结果；

MySQL

更新语句的执行流程

如果我们不需要查询用户信息，而是要更新id=1的记录中的用户名为zs，则可以通过以下SQL语句进行更新：

update user_info set name="zs" where id=1;

和上文中的查询语句类似，MySQL一样会先通过连接器建立数据库连接，然后通过分析器、优化器和执行器查找到需要更新的数据所在的行，然后更新数据。

和查询流程不一样的是，更新流程还涉及ChangeBuffer和两个重要的日志模块：BinLog和RedoLog。其中BinLog和ChangeBuffer的作用已经在前文中介绍过，BinLog用于主从复制和数据恢复，ChangeBuffer用于缓存对数据库中数据的操作，RedoLog则是本文介绍的主角了。

ChangeBuffer技术

对于上文中的更新语句，如果没有RedoLog，那么InnoDB引擎会按照索引查找到id=1的用户记录，把记录加载到内存中，然后修改内存中的数据事务提交后再写回磁盘。如果数据库数据更新的频率非常低，那么这样更新方式数据库也可以接受，但是在更新非常频繁的情况下，大量的离散IO会成为数据库的瓶颈，影响数据库的性能。

MySQL

在更新频繁的场景下，如何降低磁盘的IO并保证事务呢？这就涉及到我们前边文章中介绍过的ChangeBuffer技术了，在满足ChangeBuffer缓存操作的条件下，InnoDB并不会立即把数据的变更操作写入磁盘，而是将这些对数据页的操作缓存到ChangeBuffer中，数据库找合适的机会再将操作Merge到数据库中。

MySQL

通过ChangeBuffer技术，我们可以把对数据库的多次离散访问合并为一次数据库访问，并且用户的更新线程中不需要实际访问磁盘，大大提升了数据库性能。

WAL技术

不过不知道大家有没有注意到，ChangeBuffer有一个很大的问题：如果InnoDB实例在运行期间掉电，ChangeBuffer中的缓存会丢失，从而造成数据库数据的不一致，影响数据库事务的原子性和一致性。

数据库中保证事务原子性和一致性通用的方案是采用WAL（Write-ahead logging，预写式日志）技术，在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中，日志通常包含redo和undo两部分信息。

  • RedoLog称为重做日志，每当有操作时，在数据变更之前将操作写入RedoLog，这样当发生掉电之类的情况时系统可以在重启后继续操作；
  • UndoLog称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态；

MySQL的InnoDB引擎中就使用了WAL技术，所以InnoDB存储引擎包含了RedoLog和UndoLog两部分日志。

如何确保已经提交的事务不会丢失？解决这个问题比较简单，InnoDB有一个Log-Force-at-Commit机制，在事务提交的时候，和这个事务相关的RedoLog数据，包括Commit记录，都必须从LogBuffer中写入RedoLog文件，此时事务提交成功的信号才能发送给用户进程。通过这个机制，可以确保哪怕这个已经提交的事务中的部分ChangeBuffer还没有被写入数据文件，就发生了实例故障，在做实例恢复的时候，也可以通过RedoLog的信息，将不一致的数据前滚。

RedoLog和BinLog比较

RedoLog和BinLog不同。虽然BinLog中也记录了InnoDB表的很多操作，也能实现重做的功能，但是它们之间有很大区别。

  1. BinLog是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而RedoLog是Innodb引擎层产生的，只记录该存储引擎中表的修改；
  2. BinLog记录数据变更的逻辑性的语句，如某一行数据的的变更情况或此次变更的SQL语句。而RedoLog是在物理格式上的日志，它记录的是数据库中每个页的修改；
  3. BinLog只在每次事务提交的时候一次性写入缓存中的日志"文件"(对于非事务表的操作，则是每次执行语句成功后就直接写入)。而RedoLog在数据准备修改前写入缓存中的RedoLog中，然后才对缓存中的数据执行修改操作；而且保证在发出事务提交指令时，先向缓存中的RedoLog写入磁盘日志，写入完成后才执行提交动作；
  4. BinLog只在提交的时候一次性写入，所以BinLog记录方式和提交顺序有关，且一次提交对应一次记录。而RedoLog中是记录的物理页的修改，RedoLog文件中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1，可能在RedoLog中记录了T1-1,T1-2,T1-3，T1共4个操作，其中T1表示最后提交时的日志记录，所以对应的数据页最终状态是T1对应的操作结果。而且RedoLog是并发写入的，不同事务之间的不同版本的记录会穿插写入到RedoLog文件中，例如可能RedoLog的记录方式如下： T1-1,T1-2,T2-1,T2-2,T2,T1-3,T1* 。

事务日志记录的是物理页的情况，它具有幂等性，因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的，例如新插入一行后又删除该行，前后状态没有变化。而二进制日志记录的是所有影响数据的操作，记录的内容较多。例如插入一行记录一次，删除该行又记录一次。

RedoLog

RedoLog包括两部分：一是内存中的日志缓冲(RedoLog Buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(RedoLog File)，该部分日志是持久的。

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

为了确保每次日志都能写入到事务日志文件中，在每次将RedoLog Buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MariaDB/MySQL是工作在用户空间的，MariaDB/MySQL的RedoLog Buffer处于用户空间的内存中。要写入到磁盘上的RedoLog Buffer中，中间还要经过操作系统内核空间的操作系统缓存区，调用fsync()的作用就是将操作系统缓存区中的日志刷到磁盘上的RedoLog文件中。

RedoLog事务日志文件名为ib_logfileN，如：ib_logfile0，ib_logfile1......

RedoLog把日志从缓存写入磁盘的过程如下图所示：

Redolog Fsync

MySQL支持用户自定义在事务提交时如何将日志缓存中的日志刷磁盘文件中。可以控制通过变量innodb_flush_log_at_trx_commit的值来决定。该变量有3种值：0、1、2，默认为1。但注意，这个变量只是控制事务提交时是否刷新日志缓存到磁盘。

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

日志提交刷盘方式

有一个变量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的时候性能基本都是不变的。关于这个频率是控制什么的，在后面的"刷日志到磁盘的规则"中会说。

一致性的保证

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

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

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

选择方式1时，由于每次事务提交都会写磁盘，在大量小事务提交的场景下会影响数据库的性能。

RedoLog日志块

Innodb存储引擎中，RedoLog以块为单位进行存的，每个块占512字节，这称为RedoLog日志块。不管是日志缓存中还是系统缓存以及磁盘上的RedoLog文件，RedoLog都是这样以512字节的块存储的。

日志提交刷盘方式

RedoLog记录的是数据页的变化，当一个数据页产生的变化需要使用超过492字节的RedoLog来记录，那么就会使用多个RedoLog日志块来记录该数据页的变化。

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

内存中的RedoLog缓存和磁盘中的RedoLog文件由多个日志块组成，示意图如下所示：

日志提交刷盘方式

RedoLog日志组

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

mysql>  show global variables like "innodb_log%";
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| innodb_log_buffer_size      | 16777216 |
| innodb_log_checksums        | ON       |
| innodb_log_compressed_pages | ON       |
| innodb_log_file_size        | 50331648 |
| innodb_log_files_in_group   | 2        |
| innodb_log_group_home_dir   | ./       |
| innodb_log_write_ahead_size | 8192     |
+-----------------------------+----------+
7 rows in set (0.06 sec)

root@b48ce1e480fd:/var/lib/mysql# ls -l ib*
-rw-r----- 1 mysql root       407 Oct 21 09:36 ib_buffer_pool
-rw-r----- 1 mysql mysql 50331648 Oct 26 09:00 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Oct 20 07:24 ib_logfile1
-rw-r----- 1 mysql mysql 79691776 Oct 26 09:00 ibdata1
-rw-r----- 1 mysql mysql 12582912 Oct 26 09:00 ibtmp1

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

在Innodb将日志缓存中的RedoLog日志块刷到RedoLog文件中时，会以追加写入的方式循环轮训写入。即先在第一个RedoLog文件（即ib_logfile0）的尾部追加写，直到满了之后向第二个RedoLog文件（即ib_logfile1）写。当第二个RedoLog文件满了会清空一部分第一个RedoLog文件继续写入。

由于是将日志缓存中的日志刷到RedoLog文件，所以在RedoLog文件中记录日志的方式也是RedoLog日志块的方式。RedoLog文件的大小对Innodb的性能影响非常大，设置的太大，恢复的时候就会时间较长，设置的太小，就会导致在写RedoLog的时候循环切换RedoLog文件。

在每个组的第一个RedoLog文件中，前2KB记录4个特定的部分，从2KB之后才开始记录RedoLog日志块。除了第一个RedoLog文件中会记录，RedoLog日志组中的其他RedoLog文件不会记录这2KB，但是却会腾出这2KB的空间。

RedoLog日志组

RedoLog文件格式

Innodb存储引擎存储数据的单元是页，所以RedoLog也是基于页的格式来记录的。默认情况下，Innodb的页大小是16KB(由innodb_page_size变量控制)，一个页内可以存放多个RedoLog日志块(每个512字节)，而RedoLog日志块中记录的又是数据页的变化。

其中RedoLog日志块中492字节的部分是RedoLog内容，该RedoLog内容的格式分为4部分：

  • redo_log_type：占用1个字节，表示RedoLog的日志类型；
  • space：表示表空间的ID，采用压缩的方式后，占用的空间可能小于4字节；
  • page_no：表示页的偏移量，同样是压缩过的；
  • redo_log_body表示每个重做日志的数据部分，恢复时会调用相应的函数进行解析。

RedoLog记录格式

RedoLog的本质上是记录事务对数据库做了哪些修改。 InnoDB的设计者们针对事务对数据库的不同修改场景定义了多种类型的RedoLog日志，但是绝大部分类型的redo日志都有下边这种通用的结构：

日志通用格式

各个部分的详细释义如下：

  • type：该条redo日志的类型。在MySQL 5.7.21这个版本中，InnoDB中的redo日志包含53种不同的类型，稍后会详细介绍不同类型的redo日志。
  • space ID：表空间ID。
  • page number：页号。
  • data：该条redo日志的具体内容。

关于RedoLog更详细的格式本文就不详细做介绍，有兴趣的可以自己查找文档了解一下。我们到此处应该知道，如果我们使用Insert语句向数据库中插入一条记录，那么RedoLog会记录要在指定空间的指定数据页的指定地址处设置指定的值。

RedoLog刷盘策略

变量innodb_flush_log_at_trx_commit的值为1时，、事务每次提交的时候都会刷RedoLog事务日志到磁盘中，但是Innodb不仅仅只会在有ICommit动作后才会刷日志到磁盘，这只是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位置。

刷脏和CheckPoint

内存中(BufferPool)未刷到磁盘的数据称为脏数据(DirtyData)。由于数据和日志都以页的形式存在，所以脏页表示脏数据和脏日志。上一节介绍了日志是何时刷到磁盘的，不仅仅是日志需要刷盘，脏数据页也一样需要刷盘。

在Innodb中，数据刷盘的规则只有一个：Checkpoint。但是触发Checkpoint的情况却有几种。不管怎样，Checkpoint触发后，会将缓存中脏数据页和脏日志页都刷到磁盘。

innodb存储引擎中Checkpoint分为两种：

  • Sharp Checkpoint：在重用RedoLog文件(例如切换日志文件)的时候，将所有已记录到RedoLog中对应的脏数据刷到磁盘。
  • Fuzzy Checkpoint：一次只刷一小部分的日志到磁盘，而非将所有脏日志刷盘。有以下几种情况会触发该检查点：
    1. Master Thread Checkpoint：由Master线程控制，每秒或每10秒刷入一定比例的脏页到磁盘；
    2. flush_lru_list checkpoint：从MySQL5.6开始可通过innodb_page_cleaners变量指定专门负责脏页刷盘的PageCleaner线程的个数，该线程的目的是为了保证lru列表有可用的空闲页；
    3. Async/Sync Flush Checkpoint：同步刷盘还是异步刷盘。例如还有非常多的脏页没刷到磁盘(非常多是多少，有比例控制)，这时候会选择同步刷到磁盘，但这很少出现；如果脏页不是很多，可以选择异步刷到磁盘，如果脏页很少，可以暂时不刷脏页到磁盘；
    4. Dirty Page Too Much Checkpoint：脏页太多时强制触发检查点，目的是为了保证缓存有足够的空闲空间。Too Much的比例由变量innodb_max_dirty_pages_pct控制，MySQL 5.6默认的值为75，即当脏页占缓冲池的百分之75后，就强制刷一部分脏页到磁盘。由于刷脏页需要一定的时间来完成，所以记录检查点的位置是在每次刷盘结束之后才在RedoLog中标记的。

MySQL停止时是否将脏数据和脏日志刷入磁盘，由变量innodb_fast_shutdown={ 0|1|2 }控制，默认值为1，即停止时只做一部分purge，忽略大多数flush操作(但至少会刷日志)，在下次启动的时候再flush剩余的内容，实现FastShutdown。

LSN学习

LSN称为日志的逻辑序列号(Log Sequence Number)，在Innodb存储引擎中，LSN占用8个字节，LSN的值会随着日志的写入而递增。分析LSN可以得到很多关键信息：

  1. 数据页的版本信息。
  2. 写入的日志总量，通过LSN开始号码和结束号码可以计算出写入的日志量。
  3. CheckPoint的位置。

LSN不仅存在于RedoLog中，还存在于数据页中，在每个数据页的头部，有一个fil_page_lsn记录了当前页最终的LSN值是多少。通过数据页中的LSN值和RedoLog中的LSN值比较，如果页中的LSN值小于RedoLog中LSN值，则表示数据丢失了一部分，这时候可以通过RedoLog的记录来恢复到RedoLog中记录的LSN值时的状态。

RedoLog的LSN信息可以通过show engine innodb status来查看。MySQL 5.5版本的show结果中只有3条记录，没有pages flushed up to。

mysql> show engine innodb status
......
---
LOG
---
Log sequence number 12734454
Log flushed up to   12734454
Pages flushed up to 12734454
Last checkpoint at  12734445
0 pending log flushes, 0 pending chkp writes
45 log i/o's done, 0.00 log i/o's/second

其中

  • log sequence number就是当前的RedoLog中的LSN，通常和缓存中的LSN一致，称为缓存日志LSN；
  • log flushed up to是磁盘上RedoLog文件中的LSN，通常会比日志缓存LSN小，称为磁盘日志LSN；
  • pages flushed up to是已经刷到磁盘数据页上的LSN，称为磁盘数据页LSN；
  • last checkpoint at是上一次检查点所在位置的LSN，称为CheckPoint LSN。

Innodb执行修改数据库语句的流程如下所示：

  1. 向RedoLog缓存中写入RedoLog，并在RedoLog中记录对应的LSN，记为缓存日志LSN；
  2. 如果目标数据页在缓存中，修改缓存中的数据页，并在数据页中记录LSN，记为缓存数据页LSN；
  3. 日志刷回磁盘时，在RedoLog文件中记录对应的LSN，记为磁盘日志LSN；
  4. CheckPoint刷脏时缓存数据页中的LSN，记为CheckPoint LSN；
  5. Checkpoint要刷入的数据页多时，刷入所有的数据页需要一定的时间来完成，中途刷入的每个数据页都会记下当前页所在的LSN，暂且称之为磁盘数据页LSN。

如下图展示了一个事务过程中各个LSN的变化情况：

  1. 12:00:00.000时刻，事务开始，初始时假设各个LSN均为001；
  2. 12:00:00.200时刻，执行更新语句1，更新缓存日志LSN和缓存数据页LSN，分别加1，变更为001；
  3. 12:00:00.400时刻，执行更新语句2，更新缓存日志LSN和缓存数据页LSN，分别加1，变更为002；
  4. 12:00:00.600时刻，执行更新语句3，更新缓存日志LSN和缓存数据页LSN，分别加1，变更为003；
  5. 12:00:01.000时刻，Checkpoint，将缓存中的日志和数据页刷回磁盘，磁盘数据页和磁盘日志的LSN更新为003，Checkpoint LSN更新为003；
  6. 12:00:01.200时刻，执行更新语句3，更新缓存日志LSN和缓存数据页LSN，分别加1，变更为004；
  7. 12:00:01.400时刻，事务提交，缓存日志写入磁盘，磁盘日志LSN更新为004；
  8. 12:00:02.000时刻，Checkpoint，将缓存中的日志和数据页刷回磁盘，磁盘数据页LSN更新为004，Checkpoint LSN更新为004；

LSN更新

Innodb Crash-Safe

在启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为RedoLog记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如BinLog)要快很多。而且，Innodb自身也做了一定程度的优化，让恢复速度变得更快。

重启Innodb时，Checkpoint表示已经完整刷到磁盘上数据页的LSN，因此恢复时仅需要恢复从Checkpoint开始的日志部分。例如，当数据库在上一次Checkpoint的LSN为10000时宕机，且事务是已经提交过的状态。启动数据库时会检查磁盘中数据页的LSN，如果数据页的LSN小于日志中的LSN，则会从Checkpoint开始恢复。

还有一种情况，在宕机前正处于Checkpoint的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度。这时候一宕机，数据页中记录的LSN就会大于日志页中的LSN，在重启的恢复过程中会检查到这一情况，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。

另外，事务日志具有幂等性，所以多次操作得到同一结果的行为在日志中只记录一次。而二进制日志不具有幂等性，多次操作会全部记录下来，在恢复的时候会多次执行二进制日志中的记录，速度就慢得多。例如，某记录中id初始值为2，通过update将值设置为了3，后来又设置成了2，在事务日志中记录的将是无变化的页，根本无需恢复；而二进制会记录下两次update操作，恢复时也将执行这两次update操作，速度比事务日志恢复更慢。

RedoLog相关变量

  • innodb_flush_log_at_trx_commit={0|1|2}：指定何时将事务日志刷到磁盘，默认为1；
    1. 0表示每秒将"log buffer"同步到"os buffer"且从"os buffer"刷到磁盘日志文件中；
    2. 1表示每事务提交都将"log buffer"同步到"os buffer"且从"os buffer"刷到磁盘日志文件中；
    3. 2表示每事务提交都将"log buffer"同步到"os buffer"但每秒才从"os buffer"刷到磁盘日志文件中；
  • innodb_log_buffer_size：log buffer的大小，默认8M
  • innodb_log_file_size：事务日志的大小，默认5M
  • innodb_log_files_group =2：事务日志组中的事务日志文件个数，默认2个
  • innodb_log_group_home_dir =./：事务日志组路径，当前目录表示数据目录
  • innodb_mirrored_log_groups =1：指定事务日志组的镜像组个数，但镜像功能好像是强制关闭的，所以只有一个RedoLog日志组。在MySQL5.7中该变量已经移除。

UndoLog

基本概念

UndoLog有两个作用：提供回滚和多个行版本控制(MVCC)。

WAL技术在数据修改的时，不仅记录了RedoLog，还记录了相对应的UndoLog，如果因为某些原因导致事务失败或回滚了，可以借助该UndoLog进行回滚。

UndoLog和RedoLog记录物理日志不一样，它是逻辑日志。可以认为当Delete一条记录时，UndoLog中会记录一条对应的Insert记录，反之亦然；当update一条记录时，它记录一条对应相反的update记录。

当执行Rollback时，就可以从UndoLog中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过UndoLog来实现的：当读取的某一行被其他事务锁定时，它可以从UndoLog中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

UndoLog是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个UndoLog Segment。

另外，UndoLog也会产生RedoLog，因为UndoLog也要实现持久性保护。

UndoLog存储方式

Innodb存储引擎对Undo的管理采用段的方式。Rollback Segment称为回滚段，每个回滚段中有1024个UndoLog Segment。

在以前老版本，只支持1个Rollback Segment，这样就只能记录1024个UndoLog Segment。后来MySQL5.5可以支持128个Rollback Segment，即支持128*1024个Undo操作，还可以通过变量innodb_undo_logs(5.6版本以前该变量是 innodb_rollback_segments)自定义多少个Rollback Segment，默认值为128。UndoLog默认存放在共享表空间中。

root@b48ce1e480fd:/var/lib/mysql# ls -l ib*
-rw-r----- 1 mysql root       407 Oct 21 09:36 ib_buffer_pool
-rw-r----- 1 mysql mysql 50331648 Oct 26 09:00 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Oct 20 07:24 ib_logfile1
-rw-r----- 1 mysql mysql 79691776 Oct 26 09:00 ibdata1
-rw-r----- 1 mysql mysql 12582912 Oct 26 09:00 ibtmp1

如果开启了innodb_file_per_table，UndoLog将存储在每个表的.ibd文件中。在MySQL5.6中，undo的存放位置还可以通过变量innodb_undo_directory来自定义存放目录，默认值为"."表示datadir。

默认Rollback Segment全部写在一个文件中，但可以通过设置变量innodb_undo_tablespaces平均分配到多少个文件中。该变量默认值为0，即全部写入一个表空间文件。该变量为静态变量，只能在数据库示例停止状态下修改，如写入配置文件或启动时带上对应参数。

更新语句与UndoLog

当事务提交的时候，Innodb不会立即删除UndoLog，因为后续还可能会用到UndoLog，如隔离级别为Repeatable-Read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即UndoLog不能删除。

但是在事务提交的时候，会将该事务对应的UndoLog放入到删除列表中，未来通过Purge来删除。并且提交事务时，还会判断UndoLog分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的UndoLog页而浪费存储空间和性能。

通过UndoLog记录Delete和Update操作的结果发现：(insert操作无需分析，就是插入行而已)

  • Delete操作实际上不会直接删除，而是将Delete对象打上Delete flag，标记为删除，最终的删除操作是Purge线程完成的。
  • Update分为两种情况：update的列是否是主键列。如果不是主键列，在UndoLog中直接反向记录是如何Update的，即update是直接进行的；如果是主键列，update分两部执行：先删除该行，再插入一行目标行。

UndoLog中包含了旧版本数据行的快照信息，存储在表空间。

BinLog和事务日志

如下图所示，事务提交时，涉及到写日志的地方有三个步骤：

  • 写入RedoLog，处于Prepare状态
  • 写binlog
  • 修改redo log状态为commit

数据更新流程

这里我们注意到在 redo log 的提交过程中引入了两阶段提交。为什么必须有 “两阶段提交” 呢？这是为了让两份日志之间的逻辑一致。

由于RedoLog和BinLog是两个独立的逻辑，如果不用两阶段提交，要么就是先写完RedoLog再写BinLog，或者采用反过来的顺序，我们看看这两种方式会有什么问题，用上面的更新示例做假设：

  • 先写RedoLog后写BinLog。假设在RedoLog写完，BinLog还没有写完的时候，MySQL进程异常重启。因为RedoLog已经写完，系统即使崩溃仍然能够把数据恢复回来。但是BinLog里面就没有记录这个语句，因此备份日志的时候BinLog里面就没有这条语句；如果需要用这个BinLog来恢复临时库的话，由于这个语句的BinLog丢失，恢复出来的值就与原库值不同。
  • 先写BinLog后写RedoLog。如果在BinLog写完之后宕机，由于RedoLog还没写，崩溃恢复以后这个事务无效，所以这一行的值还是未更新以前的值。但是BinLog里面已经记录了崩溃前的更新记录，BinLog来恢复的时候就多了一个事务出来与原库的值不同。

可以看到，两阶段提交就是为了防止BinLog和RedoLog不一致发生。同时我们也注意到为了这个崩溃恢复的一致性问题引入了很多新的东西，也让系统复杂了很多，所以有得有失。二阶段提交RedoLog和BinLog的过程中，两者刷盘之后都会记录2PC事务的XID（RedoLog和BinLog中事务落盘的标识），若中途数据库Crash，通过XID关联两者并在恢复时决定commit和rollback与否，详细步骤见下一段“恢复步骤”。

恢复步骤

RedoLog中的事务如果经历了二阶段提交中的Prepare阶段，则会打上Prepare标识，如果经历Commit阶段，则会打上Commit标识（此时RedoLog和BinLog均已落盘）：

  1. 按顺序扫描RedoLog，如果RedoLog中的事务既有Prepare标识，又有Commit标识，就直接提交（复制RedoLog Disk中的数据页到磁盘数据页）；
  2. 如果RedoLog事务只有Prepare标识，没有Commit标识，则说明当前事务在Commit阶段Crash了，RedoLog中当前事务是否完整未可知，此时拿着RedoLog中当前事务的XID（RedoLog和BinLog中事务落盘的标识），去查看binlog中是否存在此XID：
    • 如果BinLog中有当前事务的XID，则提交事务（复制RedoLog disk中的数据页到磁盘数据页）；
    • 如果BinLog中没有当前事务的XID，则回滚事务（使用UndoLog来删除redolog中的对应事务）；

可以将MySQL中的RedoLog和BinLog二阶段提交和广义上的二阶段提交进行对比，广义上的二阶段提交，若某个参与者超时未收到协调者的ack通知，则会进行回滚，回滚逻辑需要开发者在各个参与者中进行记录。MySql二阶段提交是通过xid进行恢复。

组提交

为了提高性能，通常会将有关联性的多个数据修改操作放在一个事务中，这样可以避免对每个修改操作都执行完整的持久化操作。这种方式，可以看作是人为的组提交(group commit)。除了将多个操作组合在一个事务中，记录binlog的操作也可以按组的思想进行优化：将多个事务涉及到的BinLog一次性Flush，而不是每次Flush一个Binlog。

事务在提交的时候不仅会记录事务日志，还会记录二进制日志，但是它们谁先记录呢？BinLog是MySQL的上层日志，先于存储引擎的事务日志被写入。

在MySQL5.6以前，当事务提交(即发出Commit指令)后，MySQL接收到该信号进入Commit Prepare阶段；进入Prepare阶段后，立即写内存中的BinLog日志，写完内存中的BinLog日志后就相当于确定了Commit操作；然后开始写内存中的事务日志；最后将BinLog日志和事务日志刷盘，它们如何刷盘，分别由变量sync_binlog和innodb_flush_log_at_trx_commit控制。

但因为要保证BinLog日志和事务日志的一致性，在提交后的Prepare阶段会启用一个prepare_commit_mutex锁来保证它们的顺序性和一致性。但这样会导致开启BinLog日志后Group Commmit失效，特别是在主从复制结构中，几乎都会开启BinLog日志。在MySQL5.6中进行了改进。提交事务时，在存储引擎层的上一层结构中会将事务按序放入一个队列，队列中的第一个事务称为Leader，其他事务称为Follower，Leader控制着Follower的行为。虽然顺序还是一样先刷BinLog，再刷事务日志，但是机制完全改变了：删除了原来的prepare_commit_mutex行为，也能保证即使开启了BinLog，Group Commit也是有效的。

MySQL5.6中分为3个步骤：flush阶段、sync阶段、commit阶段：

  • flush阶段：向内存中写入每个事务的BinLog；
  • sync阶段：将内存中的BinLog日志刷盘。若队列中有多个事务，那么仅一次fsync操作就完成了二进制日志的刷盘操作。这在MySQL5.6中称为BLGC(binary log group commit)；
  • commit阶段：Leader根据顺序调用存储引擎层事务的提交，由于Innodb本就支持Group Commit，所以解决了因为锁prepare_commit_mutex而导致的Group Commit失效问题；

在flush阶段写入BinLog到内存中，但是不是写完就进入sync阶段的，而是要等待一定的时间，多积累几个事务的binlog一起进入sync阶段，等待时间由变量binlog_max_flush_queue_time决定，默认值为0表示不等待直接进入sync，设置该变量为一个大于0的值的好处是group中的事务多了，性能会好一些，但是这样会导致事务的响应时间变慢，所以建议不要修改该变量的值，除非事务量非常多并且不断的在写入和更新。

进入到sync阶段，会将Binlog从内存中刷入到磁盘，刷入的数量和单独的Binlog日志刷盘一样，由变量sync_binlog控制。

当有一组事务在进行commit阶段时，其他新事务可以进行flush阶段，它们本就不会相互阻塞，所以Group Commit会不断生效。当然，group commit的性能和队列中的事务数量有关，如果每次队列中只有1个事务，那么group commit和单独的commit没什么区别，当队列中事务越来越多时，即提交事务越多越快时，group commit的效果越明显。

我是御狐神，欢迎大家关注我的微信公众号:wzm2zsd

qrcode_for_gh_83670e17bbd7_344-2021-09-04-10-55-16

参考文档

MySQL实战45讲<br>
什么是 WAL<br>
详细分析MySQL事务日志(redo log和undo log)<br>
说过的话就一定要办到 —— redo 日志（上）<br>

本文最先发布至微信公众号，版权所有，禁止转载！

posted @ 2021-12-14 18:10  御狐神  阅读(889)  评论(0)  编辑  收藏  举报