InnoDB 存储引擎<六> Redo log

目录

关于Redo Log 的一些其余问题

小结


本篇承接自InnoDB存储引擎<五>的内容

InnoDB 存储引擎<五>

关于Redo Log 的一些其余问题

4.不同⽇志类型对应了哪些操作?

分析过程:
1.⽇志类型总体可以分为三⼤类,分别是:⽤于数据⻚的⽇志类型、⽤于表空间⽂件的⽇志类型和提供额外信息的⽇志类型,不同的⽇志类型对应的⽇志内容也不尽相同,⽽进⾏DML操作时,⼤多数RedoLog属于⽤于数据⻚的⽇志类型
2.属于⽤于数据⻚的⽇志类型中的⼏种最常⻅数据操作所对应的⽇志类型如下:
(1)MLOG_WRITE_STRING = 30 type 对应的值为30,表⽰在⻚⾯的某个偏移量处写⼊⼀个字符串,由于字符串的⻓度不固定,需要⽤到⼀个表⽰⻓度的区域记录,此时⽇志内容格式 .如下图所⽰:

(2)MLOG_4BYTES = 4, type 对应的值为4, 这种类型应⽤于对固定⻓度值的修改,⽐如修

改整型字段,由于⻓度固定,所以⽤于表⽰⻓度的区域可以省略,从⽽尽可能的减少空间使
⽤,此时⽇志内容格式如下图所⽰:

(3)类似的类型还有 MLOG_1BYTE = 1 , MLOG_2BYTES = 2 , MLOG_8BYTES = 8 分别表
⽰固定修改1字节、2字节、8字节的数据,⽇志格式与 MLOG_4BYTES = 4 相同
 (4)还有其他⼀些⽇志类型,⽐如:
      MLOG_REC_INSERT_8027 = 9 ,表⽰写⼊⼀条⾏格式为⾮紧凑型的记录,对应的⾏格
      式为Redundant
      MLOG_COMP_REC_INSERT_8027 = 38 ,表⽰写⼊⼀条⾏格式为紧凑型的记录,对应
      的格式为Compact、Dynamic和Compressed
      MLOG_REC_UPDATE_IN_PLACE_8027 = 13 ,表⽰更新⼀条记录
      MLOG_REC_DELETE_8027 = 14 ,表⽰从数据⻚中删除⼀条记录
      MLOG_LIST_END_DELETE_8027 = 15 ,表⽰从索引⻚中删除最后⼀条记录
      MLOG_LIST_START_DELETE_8027 = 16 ,表⽰从索引⻚中删除第⼀条记录
      MLOG_LIST_END_DELETE_8027 MLOG_LIST_START_DELETE_8027 配合可以删
      除索引⻚中⼀个范围的记录,⽽不⽤记录每⼀条记录的删除⽇志
      MLOG_PAGE_CREATE = 19 ,表⽰创建⼀个索引⻚,这个类型是关于⻚的类型
3. 属于⽤于表空间⽂件的⽇志类型:
     MLOG_FILE_CREATE = 33 ,表⽰创建⼀个.ibd表空间⽂件
    MLOG_FILE_RENAME = 34 ,表⽰重命名⼀个表空间⽂件
     MLOG_FILE_DELETE = 35 ,表⽰删除⼀个表空间⽂件
4.属于提供额外信息的⽇志类型:
MLOG_MULTI_REC_END = 31 ,只由⼀个字节的 Type 构成,⽤于标识⼀个 Mini-
Transaction(MTR)的结尾。
解答问题
不同的⽇志类型对应的⽇志内容和作⽤各不相同
1.⽤于数据⻚的⽇志类型
主要记录数据⻚的修改,⽐如创建和删除数据⻚,以及对数据的增删改查操作
2.⽤于表空间⽂件的⽇志类型 :主要记录对表空间⽂件的修改
3.提供额外信息的⽇志类型:主要标记⼀个Mini-Transaction的结尾
衍⽣问题
如果⼀个DML操作修改了表中的多个字段,⽇志如何表⽰?
通常情况下,⼀个DML操作会修改表中的多个字段,也可能修改多条记录,对于正常的增删改对应不同的⽇志类型,对应⽇志所包含的主要信息如下图所⽰:

1.新增操作:主要包含数据⻚内的偏移量,主键信息,新增的字段个数,每个字段的内容的实际⻓度,具体的内容等
2.删除操作:主要包含数据⻚内的偏移量,主键信息、旧事务的Id,旧roll_pointer,是否删除标识
3.更新操作:主要包含数据⻚内的偏移量,主键信息、旧事务的Id,旧roll_pointer,被更新字段的数据,每个被更新字段的实际⻓度,更新的具体内容
小结:
Redo Log的作⽤是把事务在执⾏过程中对数据库所做的所有修改都记录下来,以便在系统崩
溃重启后可以把事务所做的修改都恢复出来

5.什么是Mini-Transaction?

分析过程:

1.DML操作会对数据⻚产⽣什么样的影响? 

以⼀个Insert操作为例,对数据⻚的影响⼀般分为两种情况:
(1)如果写⼊记录所在的数据⻚空间充⾜,⾜够存储⼀条将要写⼊的记录,那么就可以直接写⼊,如下图所⽰:

(2)如果写⼊的数据⻚空间不充⾜,⽆法放下这条记录,由于在数据⻚中真实数据是按主键顺序排列的,那么就要新建⼀个数据⻚,对原来的数据进⾏调整,把⼀部分数据复制到新的数据⻚中,以便在⽬标数据⻚上留出⾜够的空间来保存即将写⼊的记录,此时对应的⽰意图如下所⽰:

(3)通过以上两种情况下插⼊⼀条记录的分析可以看出,当数据⻚空间充⾜的情况下可以直接写⼊数据,并记录⼀条对应RedoLog即可
(4)当数据⻚空间不充⾜⽆法放下这条记录的情况下,会创建⼀个新数据⻚,同时还有数据的复制和写⼊,索引树⾮叶⼦节点上修改,在实际的执⾏过程中还有对表空间中段、区中统计信息的修改等等,这意味⼀个简单的Insert操作有会产⽣很多条RedoLog。
2. 在记录RedoLog时服务器崩溃了导致⽇志不完整怎么办?
那么这时有⼀个问题需要考虑,试想⼀下如果执⾏这⼀系统操作的时候,RedoLog只记录了⼀半服务器就崩溃了,那么当服务器重启的时候如果按照RedoLog进⾏恢复,得到的结果肯定是错误的,所以在记录RedoLog的时候要保证⼀个DML所对应的⼀系列⽇志必须是完整的才可以执⾏恢复操作,否则就不执⾏恢复,那么怎么才能标记DML操作对应的日志是完整的?
3. Mini-Transaction的定义
(1)Mini-Transaction就是针对以上的操作过程定义的概念,也就是说把记录⼀个DML操作的过程称为⼀个 Mini-Transaction ,简称 MTR ⼀个所谓的MTR包含⼀个DML操作产⽣的⼀组完整⽇志,在进⾏崩溃恢复时这⼀组RedoLog做为⼀个不可分割的整体
 (2)这⾥所说的不可分割的组是MySQL中定义的,常⻅的有:
        向聚簇索引对应B+树的⻚⾯中插⼊⼀条记录时产⽣的RedoLog不可分割;
        向某个⼆级索引对应B+树的⻚⾯中插⼊⼀条记录时产⽣的RedoLog不可分割;
        还有其他的⼀些对⻚⾯的访问操作时产⽣的RedoLog不可分割。
(3)每条语句根据具体的执⾏情况可能会产⽣多个MTR。(范围更新或删除,一个事务可以包含多个MTR)
解答问题
Mini-Transaction是MySQL内部对底层数据⻚的⼀个原⼦操作,包含⼀个DML操作产⽣的⼀组完整⽇志,保证数据库异常恢复时数据⻚中数据的⼀致性
衍⽣问题
1.如何标识⼀组RedoLog属于同⼀个MTR?
在执⾏DML操作的过程中,每⼀个对数据⻚的修改都会记录⼀条RedoLog,这些⽇志会被顺序记录下来,并在这组⽇志的最后加⼀条特殊的⽇志标识作为⼀个MRT的结尾,这条特殊的⽇志结构⾮常简单,只有⼀个 TYPE 字段,类型为 MLOG_MULTI_REC_END = 31 ,也就是⽇志分类中的提供额外信息的⽇志类型,⼀个MTR对应的⽇志组,如下图所⽰:

2.如果⼀个MTR中只有⼀条⽇志是否可以优化?

(1)当然可以,如果⼀个MTR只有⼀条⽇志,直接在这条⽇志后加⼀个类型为
MLOG_MULTI_REC_END = 31 的标识可以做为MTR的结尾,但这样做有点浪费空间;
(2)InnoDB为了尽可能的节省空间,在MTR只有⼀条⽇志的情况下,做了⼀个优化。通过上⾯的介绍了解了⽇志类型虽然很多,但也只有⼏⼗种,⽽⽤来表⽰⽇志类型的 TYPE
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值