ACID 特性实现

  • 事务的隔离性由锁机制实现
  • 事务的原子性、一致性和持久性由事务的redo日志和undo日志来保证
    • REDO LOG 称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性
    • UNDO LOG 称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性

REDO和UNDO都可以视为是一种恢复操作：

  • redo log：存储引擎层（innodb）生成的日志，记录的是物理级别上的页修改操作，比如页号xx、偏移量yy写入了’zzz’数据，保证数据的可靠性
  • undo log：存储引擎层（innodb）生成的日志，记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于事务回滚（undo log 记录的是每个修改操作的逆操作）和一致性非锁定读（undo log回滚行记录到某种特定的版本—-MVCC，即多版本并发控制）

REDO 日志

InnoDB存储引擎是以页为单位来管理存储空间，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool后才可以访问。

所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘（checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，保证整体的性能不会下降太快

WHY UNDO

一方面，缓冲池可以消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint 并不是每次变更的时候就触发，而是master线程隔一段时间去处理的。所以最坏的情 况就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就无法恢复。

另一方面，事务包含 持久性 的特性，对于一个已经提交的事务，在事务提交后，即使系统发生崩溃这个事务对数据库中所做的更改也不能丢失

InnoDB引擎的事务采用WAL技术（Write-Ahead Logging），就是先写日志（redo log），再写磁盘，只有日志写入成功，才算事务提交成功。当发生宕机且数据未刷到磁盘时，可以通过redo log来恢复，保证ACID中的持久性

REDO 日志特点

优点

  • redo日志降低刷盘频率
  • redo日志占用空间少

存储表空间ID、页号、偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快

特点

  • redo日志是顺序写入磁盘的

    在执行事务的过程中，每执行一条语句，就可能产生若干条redo日志，它是是按照产生的顺序写入磁盘，使用顺序IO，效率比随机IO快。

  • 事务执行过程中redo log不断记录

redo log跟bin log的区别：

redo log是存储引擎层产生的，而bin log是数据库层产生的。假设一个事务对表做10万行的记录插入，在这个过程中一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务提交，才会—次写入至bin log文件中

REDO 组成

redo log可以简单分为：

重做日志的缓冲（redo log buffer) ，保存在内存中，是易失的

在服务器启动时就向操作系统申请一大片redo log buffer连续内存空间（即redo日志缓冲区），这片内存空间被划分成若干个连续的redo log block，一个redo log block占用512字节大小

参数 说明
innodb_log_buffer_size redo log buffer大小，默认为16M，最大值为4096M，最小值为1M 
1
show variables like '%innodb_log_buffer_size%';

重做日志文件（redo log file），保存在硬盘中，是持久的

REDO日志文件名为ib_logfile0和ib_logfile1

REDO 整体流程

以一个更新事务为例，redo log 流转过程：

  1. 先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
  2. 生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
  3. 当事务commit时，将redo log buffer中的内容刷新到 redo log file，对redo logfile采用追加 写的方式
  4. 定期将内存中修改的数据刷新到磁盘中

Write-Ahead Log（预先日志持久化）：在持久化一个数据页之前，先将内存中相应的日志页持久化

REDO LOG 刷盘策略

redo log的写入并不是直接写入磁盘，InnoDB引擎会在写redo log时先写redo log buffer，之后以一定频率刷入到真正的redo log file

redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘，只是刷入到文件系统缓存（page cache）中，真正的写入会交给系统来决定。

那么对于InnoDB来说就存在问题，如果交给系统来同步，同样如果系统宕机，那么数据丢会失。 针对这种情况，InnoDB给出innodb_flush_log_at_trx_commit参数，该参数控制commit提交事务时，如何将redo log buffer中的日志刷新到redo log file

刷盘策略 说明
设置为0 表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步）
设置为1 表示每次事务提交时都将进行同步，刷盘操作（ 默认值 ）
设置为2 表示每次事务提交时都只把redo log buffer 内容写入page cache，不进行同步。由OS决定同步到磁盘文件的时刻 
1
show variables like 'innodb_flush_log_at_trx_commit';

另外，InnoDB存储引擎有一个后台线程，每隔1秒，就会把redo log buffer中的内容写到文件系统缓存page cache，然后调用刷盘操作。

没有提交事务的redo log记录也可能会刷盘，在事务执行过程redo log记录是会写入redo log buffer，它会被后台线程刷盘

除了后台线程每秒1次的轮询操作，还有一种情况，当redo log buffer占用的空间即将达到innodb_log_buffer_size（默认16M）一半时后台线程会主动刷盘

刷盘策略说明

innodb_flush_log_at_trx_commit=0

  • master thread每隔一秒进行重做日志的同步操作，实例crash最多丢一秒钟内的事务（master thread负责将缓冲池中数据异步刷新到磁盘，从而保证数据一致性）
  • 它是一种折中这做法，IO效率高于参数为1，低于参数为2，有丢失数据风险，无法保证持久性

innodb_flush_log_at_trx_commit=1

  • 只要事务提交成功，redo log记录一定在硬盘中，不会存在数据丢失情况

  • 如果事务执行期间MySQL宕机，该部分日志丢失，事务没有提交，数据不会丢失数据不会丢失，还是可以保证持久性，但是效率往往最差

  • 建议使用默认值

innodb_flush_log_at_trx_commit=2

  • 只要事务提交成功，redo log buffer中的内容只写入文件系统缓存page cache
  • 如果仅是MySQL宕机不会存在数据丢失，但是OS宕机可能有1秒数据的丢失，无法保证持久性，但是该参数下效率往往最高

写入 redo log buffer 过程

Mini-Transaction

MySQL把对底层页面中的一次原子访问的过程称为一个Mini-Transaction，简称mtr。比如，向某个索引对应的B+树中插入一条记录的过程就是一个Mini-Transaction。一个mtr可以包含一组redo日志，在进行崩溃恢复时这一组redo日志作为一个不可分割的整体。
一个事务可以包含若干条语句，每一条语句其实是由若干个mtr组成，每一个mtr又可以包含若干条redo日志：

redo 日志写入log buffer

向log buffer中写入redo日志的过程是顺序的，InnoDB提供了buf_free全局变量，该变量指明往log buffer中写入redo日志的写入位置

一个mtr执行过程中可能产生若干条redo日志，它们是一个不可分割的组，每个mtr运行过程中产生的日志先暂存到一个地方，当该mtr结束时，将过程中产生的一组redo日志再全部复制到log buffer。

假设有两个名为T1、T2的事务，每个事务都包含2个mtr：

  • 事务T1的两个mtr分别称为mtr_T1_1和mtr_T1_2
  • 事务T2的两个mtr分别称为mtr_T2_1和mtr_T2_2

每个mtr都会产生一组redo日志，用示意图来描述一下这些mtr产生的日志情况：

不同的事务可能是并发执行的，T1、T2之间的mtr可能是交替执行的。每当一个mtr执行完成时，伴随该mtr生成的一组redo日志就需要被复制到log buffer，不同事务的mtr可能是交替写入log buffer的

有的mtr产生的redo日志量非常大，比如mtr_t1_2产生的redo日志占用空间比较大，占用了3个block来存储

redo log block的结构图

redo log block是由日志头、日志体、日志尾组成。日志头占用12字节，日志尾占用8字节，一个block真正能存储的数据就是512-12-8=492字节

为什么一个block设计成512字节?

该设计和磁盘的扇区有关，机械磁盘默认的扇区就星512字节，如果你要写入的数据大于512字节，那么要写入的扇区肯定不止一个，就要涉及到盘片的转动，找到下一个扇区

假设现在需要写入两个扇区A和B，如果扇区A写入成功，而扇区B写入失败，那么就会出现非原子性的写入，而如果每次只写入和扇区的大小一样的512字节，那么每次的写入都是原子性的

真正的redo日志都是存储到占用496字节大小的log block body中，图中的log block header和log block trailer存储的是一些管理信息：

log block header

属性 说明
LOG_BLOCK_HDR_NO log buffer是由log block组成，在内部log buffer就好似一个数组。LOG_BLOCK_HDR_NO用来标记数组中的位置，占用4个字节，但是由于第一位用来判断是否是flush bit，所以最大的值为2G
LOG_BLOCK_HDR_DATA_LEN 表示block中已经使用的字节，初始值为12（log block body从第12个字节处开始）。随着往block中写入的redo日志越来也多，本属性值也跟着增长。如果log block body 已经被全部写满，那么本属性的值被设置为512
LOG_BLOCK_FIRST_REC_GROUP 代表block中第一个mtr生成的redo日志记录组的偏移（block里第一个mtr生成的第一条redo日志的偏移量)。如果该值的大小和LOG_BLOCK_HDR_DATA_LEN相同，则表示当前log block不包含新的日志
LOG_BLOCK_CHECKPOINT_NO 占用4字节，表示该log block最后被写入时的checkpoint

log block trailer

参数 说明
LOG_BLOCK_CHECKSUM 表示block的校验值，用于正确性校验

redo log file

相关参数设置

参数 说明
innodb_log_group_home_dir 指定 redo log 文件组所在的路径，默认值为./ ，表示在数据库 的数据目录下。MySQL的默认数据目录var/lib/mysql下默认有两个名为ib_logfile0 和ib_logfile1的文件，log buffer中的日志默认情况下就是刷新到这两个磁盘文件中，此redo日志文件位置可以修改
innodb_log_files_in_group 指明redo log file的个数，命名方式如：ib_logfile0，ib_logfile1…ib_logfilen。默认2个，最大100个
innodb_flush_log_at_trx_commit 控制 redo log 刷新到磁盘的策略，默认为1
innodb_log_file_size 单个 redo log 文件设置大小，默认值为 48M 。最大值为512G，注意最大值指整个 redo log 系列文件之和，即innodb_log_files_in_group * innodb_log_file_size不能大 于最大值512G

日志文件组

磁盘上的redo日志文件不只一个，而是以日志文件组的形式出现。这些文件以 ib_logfile[数字]（数字可以是0、1、2…)的形式进行命名，每个的redo日志文件大小都是一样的

在将redo日志写入日志文件组时，是从ib_logfile0开始写，如果ib_logfile0写满，就接着ib_logfile1写，依此类推。如果写到最后一个文件那就重新转到ib_logfile0继续写， 采用循环使用的方式向redo日志文件组里写数据的话，会导致后写入的redo日志覆盖掉前边写的redo日志：

总共的redo日志文件大小：innodb_log_file_size × innodb_log_files_in_group

checkpoint

在整个日志文件组中还有两个重要的属性：

  • write pos：当前记录的位置，一边写一边后移
  • checkpoint：当前要擦除的位置，也是往后推移

每次刷盘redo log记录到日志文件组中，write pos位置就会后移更新。每次MySQL加载日志文件组恢复数据时，会清空加载过的redo log记录，并把checkpoint后移更新。write pos和checkpoint之间的还空着的部分可以用来写入新的redo log记录

如果write pos追上checkpoint，表示日志文件组满了，这时候不能再写入新的redo log记录，MySQL 得停下来，清空一些记录，把checkpoint推进一下

REDO LOG 小结

InnoDB的更新操作采用的是Write Ahead Log（预先日志持久化）策略，即先写日志，再写入磁盘。

UNDO 日志

redo log是事务持久性的保证和事务原子性的保证。在事务中 更新数据的前置操 其实是要先写入一个undo log。

WHAT UNDO

事务需要保证原子性，事务中的操作要么全部完成，要么什么也不做。

但有时候事务执行到一半 会出现一些情况，比如：

  1. 事务执行过程中可能遇到各种错误，比如服务器本身的错误 ， 操作系统错误 ，甚至是突 然断电导致的错误。
  2. 程序员可以在事务执行过程中手动输入 ROLLBACK 语句结束当前事务的执行。

以上情况出现，需要进行回滚 ，这样就可以造成一个假象：这 个事务看起来什么都没做，所以符合原子性要求。

每当我们要对一条记录做改动时（可以是INSERT、DELETE、UPDATE），都需要”留一手”把回滚时所需的东西记下来：

  • 插入一条记录，至少把这条记录的主键值记下来，回滚时把这个主键值对应的记录删掉（对于每个INSERT，InnoDB存储引擎会执行一个DELETE）
  • 删除一条记录，至少把这条记录中的内容都记下来，回滚时把由这些内容组成的记录插入到表（对于每个DELETE，InnoDB存储引擎会执行一个INSERT）
  • 修改一条记录，至少把修改这条记录前的旧值都记录下来，回滚把这条记录更新为旧值（对于每个UPDATE，InnoDB存储引擎会执行一个相反的UPDATE，将修改前的行放回去）

MySQL把这些为了回滚而记录的这些内容称为撤销日志或者回滚日志（undo log）。

注意，由于查询操作SELECT并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo日志。

此外undo log会产生redo log，undo log的产生会伴随着redo log的产生，这是因为undo log也需要持久性的保护。

WHY UNDO LOG

回滚数据

undo是逻辑日志，只将数据库逻辑地恢复到原来样子。所有修改都被逻辑地取消，但是数据结构和页本身在回滚之后可能大不相同。
在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页中某几条记录，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始样子，这样会影响其他事务正在进行的工作。

MVCC

在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

UNDO 的存储结构

回滚段与undo页

InnoDB对undo log的管理采用段的方式—回滚段，每个回滚段记录了 1024 个 undo log segment ，而在每个undo log segment段中进行 undo页 的申请

  • 在 InnoDB1.1版本之前 （不包括1.1版本），只有1个rollback segment，因此支持同时在线的事务限制为 1024
  • 从1.1版本开始InnoDB支持最大 128个rollback segment ，故其支持同时在线的事务限制提高到 128*1024 
1
show variables like 'innodb_undo_logs';

虽然InnoDB1.1版本支持128个rollback segment，但是rollback segment都存储于共享表空间ibdata中。从lInnoDB1.2版本开始，可通过参数对rollback segment做进一步的设置。这些参数包括：

参数 说明
innodb_undo_directory 设置rollback segment文件所在的路径，意味rollback segment可以存放在共享表空间以外的位置，即可以设置为独立表空间。该参数的默认值为./，表示当前innoDB存储引擎的目录
innodb_undo_logs 设置rollback segment的个数，默认值为128。在InnoDB1.2版本中，该参数用来替换之前版本的参数innodb_rollback segments.
innodb_undo_tablespaces 设置构成rollback segment文件的数量，这样rollback segment可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件，该文件就代表rollback segment文件。

回滚段与事务

  1. 每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务
  2. 当一个事务开始时，会制定一个回滚段，在事务进行过程中，当数据被修改时，原始的数据会被复制到回滚段
  3. 在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的 区或者在回滚段允许的情况下扩展新的盘区来使用

  4. 回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个 undo表空间

  5. 当事务提交时，InnoDB存储引擎会做以下两件事情：

    • 将undo log放入列表中，以供之后的purge操作
    • 判断undo log所在的页是否可以重用，若可以分配给下个事务使用

回滚段中的数据分类

  1. 未提交的回滚数据（uncommitted undo information）：该数据关联的事务并未提交，用于实现读一致性，该数据不能被其他事务的数据覆盖
  2. 已经提交但未过期的回滚数据（committed undo information）：该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间影响
  3. 事务已经提交并过期的数据（expired undo information）：事务已经提交，而且数据保存时间已经超过undo retention参数指定时间，数据过期了。当回滚段满后，会优先覆盖事务已经提交并过期的数据

事务提交后并不能马上删除undo log及undo log所在的页，可能还有其他事务需要通过undo log来得到行记录之前的版本。故事务提交时将undo log放入一个链表中，是否可以最终删除undo log及undo log所在页虚purge线程来判断。

UNDO 的类型

在InnoDB存储引擎中undo log分为：

  • insert undo log：在insert操作中产生的undo log。insert操作的记录只对事务本身可见，对其他事务不可见（事务隔离性的要求），故该undo log可以在事务提交后直接删除而不需要进行purge操作
  • update undo log：记录的是对delete和updae操作产生的undo log。该undo log可能需要提供MVCC机制，不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除

UNDO LOG 的生命周期

简化过程

在更新Buffer Pool中的数据之前，需要先将该数据事务开始之前的状态写入Undo Log中。假设更新到一半出错了，就可以通对Undo Log来回滚到事务开始前。

详细生成过程

对于InnoDB引擎来说，每个行记录除了记录本身的数据之外，还有几个隐藏的列：

隐藏列 说明
DB_ROW_ID 如果没有为表显式的定义主键，并且表中也没有定义唯一索引，那么InnoDB会自动为表添加一个row_id的隐藏列作为主键
DB_TRX_ID 每个事务都会分配一个事务ID，当对某条记录发生变更时，就会将这个事务的事务ID写入trx_id中
DB_ROLL_PTR 回滚指针，本质上就是指向undo log 的指针

当执行INSERT时： 

1
2
BEGIN;
INSERT INTO user (name) VALUES ("tom");

插入的数据都会生成insert undo log，并且数据的回滚指针会指向它。undo log会记录序号、插入主键的列和值…，那么在进行rollback时通过主键直接把对应的数据删除即可

当执行UPDATE时：

对于更新的操作会产生update undo log，并且会分更新主键的和不更新主键的，假设现在执行:

1
UPDATE user SET name='Sun' WHERE id=1;

这时会把老的记录写入新的undo log，让回滚指针指向新的undo log，它的undo no是1，并且新的undo log会指向老的undo log（undo no=0）

假设现在执行：

1
UPDATE user SET id=2 WHERE id=1;

对于更新主键的操作，会先把原来的数据deletemark标识打开，此时并没有真正删除数据，真正的删除会交给清理线程去判断，然后在后面插入一条新的数据，新的数据也会产生undo log，并且undo log的序号会递增。

可以发现每次对数据的变更都会产生一个undo log，当一条记录被变更多次时，那么就会产生多条undo log，undo log记录的是变更前的日志，并且每个undo log的序号是递增的，那么当要回滚时按照序号依次向前推，就可以找到原始数据

undo log是如何回滚的

以上面的例子来说，假设执行rollback，那么对应的流程应该是这样：

  1. 通过undo no=3的日志把id=2的数据删除
  2. 通过undo no=2的日志把id=1的数据的deletemark还原成0
  3. 通过undo no=1的日志把id=1的数据的name还原成Tom
  4. 通过undo no=0的日志把id=1的数据删除

undo log的删除

  • insert undo log： insert操作的记录，只对事务本身可见，对其他事务不可见。该undo log可以在事务提交后直接删除，不需要进行purge操作

  • update undo log：该undo log可能需要提供MVCC机制，不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除

purge线程主要作用：清理undo页和清除page里面带有Delete_Bit标识的数据行。

在InnoDB中，事务中的Delete操作实际上并不是真正的删除数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，它是假删除，真正的删除工作需要后台purge线程去完成。

UNDO 小结

  • undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来样子
  • redo log是物理日志，记录的是数据页的物理变化，undo log 不是 redo log 的逆过程。