MySQL InnoDB 事务实现过程相关内容的概述

说说MySQL中的Redo log Undo log都在干啥,redoundo

    在数据库系统中,既有存放数据的文件,也有存放日志的文件。日志在内存中也是有缓存Log buffer,也有磁盘文件log file,本文主要描述存放日志的文件。     MySQL中的日志文件,有这么两类常常讨论到:undo日志与redo日志。

MySQL事务的实现涉及到redo和undo以及purge,redo是保证事务的原子性和持久性;undo是保证事务的一致性(一致性读和多版本并发控制);purge清理undo表空间
背景知识,对于Innodb表中的行每一行包括:
6字节的事务ID(DB_TRX_ID)字段: 用来标识最近一次对本行记录做修改(INSERT|UPDATE)的事务的标识符, 即最后一次修改(INSERT|UPDATE)本行记录的事务id。
7字节的回滚指针(DB_ROLL_PTR)字段: 指写入回滚段(ROLLBACK segment)的 UNDO LOG record (撤销日志记录记录)。
如果一行记录被更新, 则 UNDO LOG record 包含 '重建该行记录被更新之前内容' 所必须的信息。

1 undo

 

1.1 undo是啥

undo日志用于存放数据修改被修改前的值,假设修改 tba 表中 id=2的行数据,把Name='B' 修改为Name = 'B2' ,那么undo日志就会用来存放Name='B'的记录,如果这个修改出现异常,可以使用undo日志来实现回滚操作,保证事务的一致性。 对数据的变更操作,主要来自 INSERT UPDATE DELETE,而UNDO LOG中分为两种类型,一种是 INSERT_UNDO(INSERT操作),记录插入的唯一键值;一种是 UPDATE_UNDO(包含UPDATE及DELETE操作),记录修改的唯一键值以及old column记录。

Id Name
1 A
2 B
3 C
4 D

1,MySQL事务执行过程中,
  对于undo log
    对于update或者delete操作,每一行都保存了一个事务Id,修改事务Id为当前Session的事务id,
    生成数据行事务之前的版本,将当前行的回滚指针指向事务之前的版本。
    对于insert操作,将当前行的回滚指针指为空,因为insert没有事务操作之前的版本。
  对于redo log
    随着updatedeleteinsert操作的执行,重做日志Redo Log不断地写入重做日志缓存(redo_log_buffer),
    对于Redo Log Buffer的落盘(写入 Redo Log File),有三种策略:
    (1),事务commit的时候,
    (2),redo_log_buffer(默认8MB)使用超过50%的时候,
    (3),发生checkpoint的时候
    也就是说,Redo Log Buffe的落盘并不一定是事务提交的时候才写入的,对于大事务,redo log是有可能逐步落盘的(2,3两点的影响)

1.2 undo参数

MySQL跟undo有关的参数设置有这些:

 1 mysql> show global variables like '%undo%';
 2 +--------------------------+------------+
 3 | Variable_name            | Value      |
 4 +--------------------------+------------+
 5 | innodb_max_undo_log_size | 1073741824 |
 6 | innodb_undo_directory    | ./         |
 7 | innodb_undo_log_truncate | OFF        |
 8 | innodb_undo_logs         | 128        |
 9 | innodb_undo_tablespaces  | 3          |
10 +--------------------------+------------+
11  
12 mysql> show global variables like '%truncate%';
13 +--------------------------------------+-------+
14 | Variable_name                        | Value |
15 +--------------------------------------+-------+
16 | innodb_purge_rseg_truncate_frequency | 128   |
17 | innodb_undo_log_truncate             | OFF   |
18 +--------------------------------------+-------+
  • innodb_max_undo_log_size

    控制最大undo tablespace文件的大小,当启动了innodb_undo_log_truncate 时,undo tablespace 超过innodb_max_undo_log_size 阀值时才会去尝试truncate。该值默认大小为1G,truncate后的大小默认为10M。

  • innodb_undo_tablespaces 

    设置undo独立表空间个数,范围为0-128, 默认为0,0表示表示不开启独立undo表空间 且 undo日志存储在ibdata文件中。该参数只能在最开始初始化MySQL实例的时候指定,如果实例已创建,这个参数是不能变动的,如果在数据库配置文 件 .cnf 中指定innodb_undo_tablespaces 的个数大于实例创建时的指定个数,则会启动失败,提示该参数设置有误。 图片 1     如果设置了该参数为n(n>0),那么就会在undo目录下创建n个undo文件(undo001,undo002 ...... undo n),每个文件默认大小为10M. 图片 2 什么时候需要来设置这个参数呢?     当DB写压力较大时,可以设置独立UNDO表空间,把UNDO LOG从ibdata文件中分离开来,指定 innodb_undo_directory目录存放,可以制定到高速磁盘上,加快UNDO LOG 的读写性能。

  • innodb_undo_log_truncate

   InnoDB的purge线程,根据innodb_undo_log_truncate设置开启或关闭、innodb_max_undo_log_size的参数值,以及truncate的频率来进行空间回收和 undo file 的重新初始化。    该参数生效的前提是,已设置独立表空间且独立表空间个数大于等于2个。    purge线程在truncate undo log file的过程中,需要检查该文件上是否还有活动事务,如果没有,需要把该undo log file标记为不可分配,这个时候,undo log 都会记录到其他文件上,所以至少需要2个独立表空间文件,才能进行truncate 操作,标注不可分配后,会创建一个独立的文件undo_<space_id>_trunc.log,记录现在正在truncate 某个undo log文件,然后开始初始化undo log file到10M,操作结束后,删除表示truncate动作的 undo_<space_id>_trunc.log 文件,这个文件保证了即使在truncate过程中发生了故障重启数据库服务,重启后,服务发现这个文件,也会继续完成truncate操作,删除文件结束后,标识该undo log file可分配。

  • innodb_purge_rseg_truncate_frequency

  用于控制purge回滚段的频度,默认为128。假设设置为n,则说明,当Innodb Purge操作的协调线程 purge事务128次时,就会触发一次History purge,检查当前的undo log 表空间状态是否会触发truncate。

2,事务的提交Commit
  Redo Log Buffer的写盘,由变量innodb_flush_log_at_trx_commit决定,有三种模式分别是0,1,2
  如果设置为0,事物提交不触发Redo Log Buffer写盘,每N秒将Redo Log Buffer的记录写入Redo Log文件,并且将Redo Log文件刷入硬件存储1次,N由innodb_flush_log_at_timeout控制。
  如果设置为1,事务提交时同步刷新Redo Log Buffe到Redo Log文件,并且将Redo Log文件刷新到磁盘。
  如果设置为2,事务提交时同步刷新Redo Log Buffe到Redo Log文件,.但是Redo Log 的flush(刷到磁盘)操作并不会同时进行。Redo Log的写盘由操作系统和innodb_flush_log_at_timeout控制。
  需要注意的是,innodb_flush_log_at_trx_commit=1的情况下,尽管事务提交可以保证redo log同步写盘,
  但是Redo Log Buffer的写盘并不一定只有在事务提交的时候才写入的,有可能是随着时候的执行(如果事务很大)逐步写盘的。

1.3 undo空间管理

如果需要设置独立表空间,需要在初始化数据库实例的时候,指定独立表空间的数量。 UNDO内部由多个回滚段组成,即 Rollback segment,一共有128个,保存在ibdata系统表空间中,分别从resg slot0 - resg slot127,每一个resg slot,也就是每一个回滚段,内部由1024个undo segment 组成。 回滚段(rollback segment)分配如下:

  • slot 0 ,预留给系统表空间;
  • slot 1- 32,预留给临时表空间,每次数据库重启的时候,都会重建临时表空间;
  • slot33-127,如果有独立表空间,则预留给UNDO独立表空间;如果没有,则预留给系统表空间;

回滚段中除去32个提供给临时表事务使用,剩下的 128-32=96个回滚段,可执行 96*1024 个并发事务操作,每个事务占用一个 undo segment slot,注意,如果事务中有临时表事务,还会在临时表空间中的 undo segment slot 再占用一个 undo segment slot,即占用2个undo segment slot。如果错误日志中有:Cannot find a free slot for an undo log。则说明并发的事务太多了,需要考虑下是否要分流业务。 回滚段(rollback segment )采用 轮询调度的方式来分配使用,如果设置了独立表空间,那么就不会使用系统表空间回滚段中undo segment,而是使用独立表空间的,同时,如果回顾段正在 Truncate操作,则不分配。 图片 3

3,事务提之后
  因为redo log的存在(写盘之后),事务的一致性和持久性得到了保证,对于内存中的脏数据,通过checkpoint或者内存机制刷入磁盘,在数据写入磁盘之后,redo log空间即可释放
  对于undo log,当没有活动Session访问的时候,由purge线程异步清理undo log占用的空间

2 redo

 图片 4

2.1 redo是啥

    当数据库对数据做修改的时候,需要把数据页从磁盘读到buffer pool中,然后在buffer pool中进行修改,那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致,称buffer pool的数据页为dirty page 脏数据,如果这个时候发生非正常的DB服务重启,那么这些数据还没在内存,并没有同步到磁盘文件中(注意,同步到磁盘文件是个随机IO),也就是会发生数据丢失,如果这个时候,能够在有一个文件,当buffer pool 中的data page变更结束后,把相应修改记录记录到这个文件(注意,记录日志是顺序IO),那么当DB服务发生crash的情况,恢复DB的时候,也可以根据这个文件的记录内容,重新应用到磁盘文件,数据保持一致。     这个文件就是redo log ,用于记录 数据修改后的记录,顺序记录。它可以带来这些好处:

  • 当buffer pool中的dirty page 还没有刷新到磁盘的时候,发生crash,启动服务后,可通过redo log 找到需要重新刷新到磁盘文件的记录;
  • buffer pool中的数据直接flush到disk file,是一个随机IO,效率较差,而把buffer pool中的数据记录到redo log,是一个顺序IO,可以提高事务提交的速度;

    假设修改 tba 表中 id=2的行数据,把Name='B' 修改为Name = 'B2' ,那么redo日志就会用来存放Name='B2'的记录,如果这个修改在flush 到磁盘文件时出现异常,可以使用redo log实现重做操作,保证事务的持久性。

Id Name
1 A
2 B
3 C
4 D

      这里注意下redo log 跟binary log 的区别,redo log 是存储引擎层产生的,而binary log是数据库层产生的。假设一个大事务,对tba做10万行的记录插入,在这个过程中,一直不断的往redo log顺序记录,而binary log不会记录,知道这个事务提交,才会一次写入到binary log文件中。binary log的记录格式有3种:row,statement跟mixed,不同格式记录形式不一样。

本文由金沙官网线上发布于数据库,转载请注明出处:MySQL InnoDB 事务实现过程相关内容的概述

您可能还会对下面的文章感兴趣: