o2o网站建设公司排名,河北 保定 网站建设,做网站要不要用jsp,企业公司注册流程目录
撤销⽇志 - Undo Log
双写缓冲区 - Doublewrite Buffer
重做⽇志 - Redo Log
本篇是继承自上篇InnoDB存储引擎的磁盘文件
上篇链接#xff1a;InnoDB 存储引擎#xff1c;四#xff1e;磁盘文件一
撤销⽇志 - Undo Log 1.什么是撤销⽇志#xff1f; 解答问题InnoDB 存储引擎四磁盘文件一
撤销⽇志 - Undo Log 1.什么是撤销⽇志 解答问题 1.当事务对数据进⾏修改的时候每个修改操作都会在磁盘上创建与之对应的Undo Log当事务需要回滚时会根据Undo Log逐⼀进⾏撤销操作从⽽保证事务的原⼦性。也就是说撤销⽇志是为事务的回滚操作⽽诞⽣的机制它是⼀个撤销操作记录的集合。 2.Undo⽇志保存在Undo⽇志段中Undo⽇志段位于回滚段中回滚段位于undo表空间和全局临时表空间中 衍⽣问题: 1. 撤销⽇志的写⼊时机 在事务执⾏每个DML之前会根据DML构建对应的撤销⽇志并申请⼀个 undo log segments (撤销⽇志段)把⽇志记录在申请到的撤销段中再执⾏真正的DML操作, 执⾏过程如下所⽰ 2.撤销⽇志在撤销表空间中的组织形式是怎样的 前置知识: .Undo⽇志保存在Undo⽇志段中Undo⽇志段位于回滚段中回滚段位于undo表空间和全局临时表空间中 分析过程: 撤销⽇志在撤销表空间中的组织结构图如下图所示 1.Undo log segments (撤销⽇志段)也称为撤销段,⼀个撤销⽇志段可以保存多个事务的回滚⽇志,但在同⼀时间只能被⼀个活跃事务使⽤对应的空间在事务提交或回滚后才可以被重⽤。 2.rollback segments (回滚段)中包含撤销⽇志段通常位于undo表空间和全局临时表空间 中使⽤系统变量 Innodb_rollback_segments 可以定义分配给每个undo表空间和全局临时 表空间的回滚段的数量默认值为128取值范围是[1, 128] 3.⼀个回滚段⽀持的事务数取决于回滚段中的undo slots(槽数)和每个事务所需的undo⽇志数⼀个回滚段中的undo槽数可以根据InnoDB⻚⾯⼤⼩进⾏计算公式是(InnoDB Page Size / 16)⽐如默认情况下 InnoDB Page Size ⼤⼩为 16KB 那么⼀个回滚段就可以包含 1024 个 undo slot ⽤来存储事务的撤销⽇志。 4.回滚段中还记录了 History List 的头节点 History List Base Node 以及回滚段的⼤小 5.通过系统变量 innodb_rollback_segments 可以设置Undo表空间中的回滚段数量最⼤值 和默认值都是128 # 查看Undo表空间中的回滚段数量
mysql show variables like innodb_rollback_segments;
---------------------------------
| Variable_name | Value |
---------------------------------
| innodb_rollback_segments | 128 |
---------------------------------
1 row in set, 1 warning (0.01 sec)# 设置Undo表空间中的回滚段数量
mysql SET GLOBAL innodb_rollback_segments 128;
Query OK, 0 rows affected (0.00 sec) 解答问题: 撤销表空间中包含 rollback segments (回滚段)每个回滚段中包含若⼲undo slots(槽数) 每个槽对应⼀个 Undo log segments (撤销⽇志段)撤销⽇志段中包含具体的撤销⽇志 3.撤销⽇志的格式是怎样的(撤销日志的结构) 分析过程 撤销⽇志格式⽰意图如下与数据行的格式进行比较 解答问题 一 条记录在Undo Log⻚中的Undo Log⽇志⼤体包含两部分分别是记录了Undo类型、表ID、上 ⼀条、下⼀条⽇志的偏移地址等在内的基本信息以及记录了不同操作和数据的操作信息 衍⽣问题 1. 在事务中不同的DML操作对应的撤销⽇志是否不同?(不同的DML操作对应不同的撤销日志) 在执⾏DML语句操作数据库时不同SQL语句对应的撤销操作不同不同的撤销操作对应的Undo Log存储格式也不相同按照增、删、改等不同的DML操作⽣成对应的撤销⽇志 2.不同操作对应的撤销⽇志如何区分 (1)Undo类型有很多种最常⻅的就是增、删、改分别⽤ TRX_UNDO_INSERT_REC 、 TRX_UNDO_DEL_MARK_REC 和 TRX_UNDO_UPD_EXIST_REC 表⽰示意图如下所⽰ (2)新增( TRX_UNDO_INSERT_REC )时的Undo Log操作信息相对简单只记录了主键值主键⻓度等主键信息 (3)删除( TRX_UNDO_DEL_MARK_REC )时除了记录主键信息之外还记录了旧的事务ID旧的ROLL_POINTER信息⽤来构建有序的Undo版本链还会记录⼀些被索引字段的信息 (4)更新( TRX_UNDO_UPD_EXIST_REC )时较为复杂如果不更新主键则和删除时类似会记录主键信息、旧的事务ID、旧的ROLL_POINTER信息、被索引字段的信息和被更新的信息如果更新了主键则会记录两条Undo Log ⼀条删除的和⼀条新增的 对于更新主键的操作本质上都是删除旧的数据行新增一个新数据行 4.撤销⽇志是如何组织在⼀起的(通过撤销日志页) 分析过程 撤销⽇志的组织⽰意图如下 对于这里的undo page header,undo log segment header和undo log header中存储的主要字段信息 解答问题 1.⼀条条Undo Log会被逐⼀放在Undo Log⻚中Undo Log⻚和其他类型的⻚⼀样都会包含头尾信息除此之外还有Undo Log特有的信息包括 (1)UNDO PAGE HEADER 记录了Undo Log⻚类型、⽇志偏移位置,下⼀⻚链表引⽤等信息 (2)UNDO LOG SEGMENT HEADER 记录了回滚段信息 (3)UNDO LOG HEADER 记录了产⽣这条⽇志的事务IdTrx ID事务的提交顺序Trx No和其他事务相关信息 2.在这三个特有的头信息之外其他空间都会⽤来记录Undo Log⽇志如果某个事务很⼤⼀个Undo Log⻚没有办法完整记录就需要申请新的Undo Log⻚然后通过 UNDO PAGE HEADER 中链表引⽤信息链接到前⼀个⻚后⾯的这些⻚只需要记录Undo Log并不需要记录Undo头信息。 3.这个由Undo Log构成的链表称做Undo链在事务中会起到⾮常重要的作⽤。 衍⽣问题: 1.事务提交后Undo Log是否就可以删除了 对于新增操作所记录的Undo Log⽇志在事务提交之后就可以直接删除了⽽删除和更新的Undo Log⽇志还需要服务事务的MVCC所以并不能直接删除⽽是加⼊到 hisotry list 中。因些InnoDB为了最⼤程度节省空间提升效率对Undo Log进⾏了分类 5.撤销⽇志如何分类 前置知识 1.这里的分类是为了方便管理日志而进行的分类 2.关于上个问题中UNDO PAGE HEADER 中记录了Undo Log⻚类型意义是啥 解答问题: 1.Undo Log分为两⼤类⼀类只记录新增操作事务提交后可以直接清除另⼀类记录删除和更新操作所以相应的回滚链也会被区分为2个Insert Undo链 和 Update Undo链(Delete Update) 2.另外普通表和临时表分别对应这两类Undo链如是⼀个事务既有新增⼜有修改并且⽤到了临时表那么这个事务最多可以分配四个撤销⽇志也就是四个Undo链分别是 (1)对⽤⼾定义的普通表进⾏ INSERT 操作 (2)对⽤⼾定义的普通表进⾏ UPDATE 和 DELETE 操作 (3)对⽤⼾定义的临时表进⾏ INSERT 操作 (4)对⽤⼾定义的临时表进⾏ UPDATE 和 DELETE 操作 对于前两个是保存在系统或用户创建的撤销表空间后两个是保存在临时表空间中临时表空间中有一个回滚段专门用来保存undo 日志 3. 根据事务的操作按需要写⼊Undo⽇志⽐如在普通表和临时表执⾏ INSERT 、 UPDATE 和 DELETE 操作的事务需要会写⼊以上四种类型的撤销⽇志只在普通表上执⾏ INSERT 操作的事 务只需要⼀个撤消⽇志 4.对普通表执⾏操作的事务将从指定的系统表空间或undo表空间的回滚段分配undo⽇志。对临时表执⾏操作的事务从指定的临时表空间回滚段分配undo⽇志 6. InnoDB最⼤⽀持并发读写事务的数量如何计算 解答问题 可以⽤以下公式计算InnoDB能够⽀持的并发读写事务的数量 (1) 如果每个事务执⾏ INSERT 或 UPDATE 或 DELETE 操作注意只执⾏⼀种类型的操作并发读 写事务数为: # 最⼤⽀持 (16384 / 16) * 128 * 127 16,646,144
(innodb_page_size / 16) * innodb_rollback_segments * number of undo tablespaces 从左向右为页大小回滚段的数量以及撤销表空间的个数 (2)如果每个事务执⾏ INSERT 和 UPDATE (和的意思为一个事务要使用两个撤销日志段)或 DELETE 操作并发读写事务数为: # 最⼤⽀持 (16384 / 16 / 2) * 128 * 127 8,323,072
(innodb_page_size / 16 / 2) * innodb_rollback_segments * number of undo tablespaces (3)如果⼀个事务在临时表上执⾏ INSERT 操作并发读写事务数为: # 临时表最⼤⽀持 (16384 / 16) * 128 131,072
(innodb_page_size / 16) * innodb_rollback_segments (4)如果⼀个事务在临时表上执⾏ INSERT 和 UPDATE 或 DELETE 操作并发读写事务数为: # 临时表最⼤⽀持 (16384 / 16 / 2) * 128 65,536
(innodb_page_size / 16 / 2) * innodb_rollback_segments 7.如何理解Undo链 解答问题: 1.Insert Undo链 和 Update Undo链采⽤了不同的组织⽅式 2.对于新增操作Insert Undo链中的每个Undo Log都会对应⼀条新的数据⾏这个数据⾏中⽤ ROLL_POINTER 信息来关联Undo Log在回滚时就可以通过它找到需要回滚的Undo Log了,即一条新增的数据行对应一条undo日志他们之间是一对一的关系 3.对于删除和更新Update Undo链中的每个Undo Log也都对应⼀个数据⾏每次更新都会通过 Undo Log中的 ROLL_POINTER 进⾏关联从⽽每个数据⾏都会构成⼀个Undo Log版本链回滚的时候就可以依序撤销这个版本链在事务的MVCC中起到了⾮常重要的作⽤⽤于解决事务的隔离性 4.以下是⼀个关于更新操作的Undo链 8.撤销⽇志为什么需要落盘 分析过程 1.在对数据进⾏修改时都是在内存中操作的也就是在Buffer Pool中修改对应的数据⻚在修改数据⻚之前先把对应的撤销⽇志记录在内存中如果此时事务回滚直接根据内存中的撤销⽇志做回滚操作即可 2.在修改完成提交事务后脏⻚进⾏落盘操作此时事务已提交不能回滚所以撤销⽇志也就失效了 3.当服务器崩溃时如果事务没有提交所有的修改都在内存中还没有落盘对于修改直接丢弃如果事务已经提交则根据重做⽇志和双写缓冲区中的备份进⾏恢复 4.通过分析看上去撤销⽇志并不需要落盘其实以上的分析场景并没有考虑到全部的场景⽐如⼤事务的运⾏、MVCC中版本链什么时候可以销毁、事务的不同隔离级别等因素 解答问题undo log落盘必须在真实数据页落盘之前 1. 在运⾏⼤事务时InnoDB为了避免⼤事务提交时统⼀落盘操作带来的性能问题允许在事务进⾏ 的过程中就进⾏落盘操作并记录对应的UndoLog当发⽣崩溃恢复时通过回放UndoLog把未提 交的事务进⾏回滚 2.如果⼀个事务已经提交但还有其他事务需要访问版本链中对应的UndoLog那么也需要把相应的撤销⽇志保存到 hisotry list 中。 3.不同隔离级别下没有提交的事务也可能会落盘回滚时依然要完成撤销操作 衍⽣问题 1. 撤销⽇志在内存中如何记录 (1) 与数据⻚在内存中的保存⽅式相同撤销⽇志在内存中也保存在Buffer Pool中与磁盘中的 UndoLog⻚结构⼀致内存中每个UndoLog⻚通过控制块管理 (2) 在内存中使⽤四个链表来管理正在使⽤的UndoLog⻚和空闲UndoLog⻚根据不同的⽇志类型分 为 Insert List 正在被使⽤的⽤来管理Insert类型的UndoLog ⻚ Insert Cache List 空闲的或被清理后可以被后续事务重⽤的Insert类型UndoLog⻚ Update List 正在被使⽤的⽤来管理Update类型的UndoLog ⻚ Update Cache List 空闲的或被清理后可以被后续事务重⽤的Update类型UndoLog⻚ 2.撤销⽇志的写⼊过程是怎样的 ----先写内存再按需落盘 (1)当写事务开始时会先分配⼀个处理 ACTIVE 状态的 Rollback Segment (2)当第⼀次DML操作产⽣Undo Record时会轮询当前 Rollback Segment 中可⽤的 Slot 以便获取⼀个 Undo Log Segment (3)根据撤销⽇志的类型获取UndoLog⻚并挂载到对应的List当中 (4)在UndoLog⻚顺序写⼊⽇志当⼀个UndoLog⻚写满之后会获取新的UndoLog⻚以便继续写⼊当前事务⽣成的⽇志这⾥注意单条UndoLog不能跨⻚存储也就是说当某条⽇志在当前⻚中放不下时会整体保存下⼀⻚中 (5)由后台线程把⽇志刷⼊磁盘 (6)当事务结束之后(commit或者rollback) insert ⽇志类型对应的 Undo Log Segment 和 UndoLog page 会直接回收⽽ update ⽇志类型对应的 Undo Log Segment 和 UndoLog page 会等待后台的清理操作完成后确保⽇志不会有事务再访问后进⾏回收回收的UndoLog⻚被挂载到Cache List中 3.撤销⽇志的回滚过程是怎样的 (1)回滚操作可以是⽤⼾通过rollback主动触发也可能发⽣在崩溃恢复时不论是哪种触发条件回滚操作都是相同的基本过程就是读取该事务的Undo Log从后向前依次进⾏逆向操作从⽽恢复索引记录 (2)对于 Insert 类型的回滚操作就是 Delete 在删除的过程中会重新调整主键索引和⼆级索引 (3)对于Update和Delete类型的回滚操作主要是回退这次操作在所有主键索引和⼆级索引的影响可能包括重新插⼊被删除的⼆级索引记录、去除⾏管理信息中的Delete Mark标记、将主索引记录修改回之前的值等 (4)完成回滚的Undo Log会进⾏回收将不再使⽤的UndoLog⻚的磁盘空间还给 Undo Log Segment 这个过程是写⼊过程的逆操作。 4.撤销⽇志的清理过程是怎样的 (1)InnoDB通过保存多份Undo Log的历史版本来实现MVCC当某个历史版本已经确认不会被任何现有的和未来的事务访问时就应该被清理掉 (2)当开启⼀个事务时都会被分配⼀个事务编号 trx_id ⽽事务进⾏读操作时会创建⼀个 ReadView并记录当前所有事务中的最⼩活跃事务编号 m_low_limit_id 如果版本链中 ⽇ 志的 trx_id m_low_limit_id 则表⽰当前读操作发⽣时⽇志对应的事务已提交其修 改的新版本是可⻅的 因此不再需要通过Undo版本链构建之前的版本这个事务的Undo Log也就可以被清理了。 (3)Undo的清理⼯作是由专⻔的后台线程进⾏扫描和分发并由多个线程进⾏清理并可以通过系统变量 innodb_purge_threads 配置清理线程数系统变量 innodb_purge_batch_size 可以配置每次清理的⻚数 双写缓冲区 - Doublewrite Buffer 1.双写缓冲区的作⽤ 解答问题: 双写缓冲区是磁盘上的⼀个存储区域当 InnoDB 将缓冲池中的数据⻚写⼊到磁盘上表空间数据⽂件之前先将对应的⻚写到双写缓冲区如果在数据真正落盘的过程中出现了意外退出⽐如操作系统、存储⼦系统崩溃或异常断电的情况 InnoDB 在崩溃恢复时可以从双写缓冲区中找到⼀份完好的⻚副本 衍⽣问题: 1.双写缓冲区中的数据保存在哪⾥ 在MySQL 8.0.20之前 doublewrite 缓冲区位于InnoDB系统表空间中。从MySQL 8.0.20开 始 doublewrite 缓冲区默认存储区域位于数据⽬录下的 doublewrite ⽂件中。 rootguangchen-vm:/var/lib/mysql# ll
total 92948
drwxr-x--- 8 mysql mysql 4096 11⽉ 5 11:15 ./
drwxr-xr-x 73 root root 4096 10⽉ 30 12:07 ../
# ...省略
# 默认创建两个双写缓冲区⽂件
-rw-r----- 1 mysql mysql 196608 11⽉ 5 11:15 #ib_16384_0.dblwr # ⽂件1
-rw-r----- 1 mysql mysql 8585216 11⽉ 1 10:34 #ib_16384_1.dblwr # ⽂件2
# ...省略 2.如何配置双写缓冲区 解答问题: 1.是否启⽤ doublewrite 缓冲区可以通过系统变量 innodb_doublewrite[ON|OFF] 控制默认为启⽤如果真实的业务场景更关注性能⽽不是数据完整性可以考虑禁⽤doublewrite缓冲区例如在执⾏测试的环境中 2.doublewrite ⽂件所在⽬录通过系统变量 innodb_doublewrite_dir (MySQL 8.0.20中引⼊)指定如果不指定则在 innodb_data_home_dir ⽬录(默认为data⽬录)下创建如果指定 doublewrite⽬录建议设置在最快的存储介质上以提⾼效率 rootguangchen-vm:/var/lib/mysql# ll
total 92948
drwxr-x--- 8 mysql mysql 4096 11⽉ 5 11:15 ./
drwxr-xr-x 73 root root 4096 10⽉ 30 12:07 ../
# ...省略
# 默认创建两个双写缓冲区⽂件
-rw-r----- 1 mysql mysql 196608 11⽉ 5 11:15 #ib_16384_0.dblwr # ⽂件1
-rw-r----- 1 mysql mysql 8585216 11⽉ 1 10:34 #ib_16384_1.dblwr # ⽂件2
# ...省略
命名⽅式为 #ib_page_size_file_number.dblwr 以上 #ib_16384_0.dblwr 的⽂件 表⽰当前数据⻚的⼤⼩为16KB编号为0 3.双写⽂件的数量通过系统变量 innodb_doublewrite_files 设置默认情况下为每个缓冲 池实例创建两个doublewrite⽂件也就是说⽂件数量为 innodb_buffer_pool_instances * 2 此变量⽤于⾼级性能调优⼤多数场景使⽤默认设置即可 重做⽇志 - Redo Log 1.重做⽇志的作⽤ 解答问题 1.重做⽇志在保证事务的持久性和⼀致性⽅⾯起到了⾄关重要的作⽤ 2.重做⽇志⽤于在数据库崩溃后恢复已提交事务还没有来的及落盘的数据。重做⽇志以⽂件的形式保存在磁盘上在正常的操作过程中MySQL根据受影响的记录进⾏编码并写⼊重做⽇志⽂件这些数据称为Redo在重新启动时⾃动读取重做⽇志进⾏数据恢复。 衍⽣问题 1.为什么要⽤Redo Log⽽不是直接写磁盘 (1)⾸先明确⼀点我们对数据进⾏的DML操作都会包含在事务当中当完成修改并且提交事务之后在内存中被修改的数据⻚就要刷新到磁盘完成持久化 (2)那么如果这次DML操作对应的修改开始刷盘的话当服务器崩溃没有被刷到磁盘的数据⻚就从内存中丢失这时这个事务的修改在磁盘上就是不完整的也就是没有保证事务的⼀致性 (3)为了解决这个问题InnoDB在执⾏每个DML操作时当内存中的数据⻚修改完成之后把修改的内容以⽇志的形式保证在磁盘上然后再对数据⻚进⾏真正的落盘操作这样做就相当于对修改进⾏了⼀次备份即使当服务器崩溃也不会受到影响当服务器重启之后可以从磁盘上的⽇志⽂件中找到上次崩溃之前没有来的及落盘的数据继续执⾏落盘操作 (4)InnoDB引擎的事务采⽤了 WAL 技术 (Write-Ahead Logging) 基本思想是先写⽇志再写磁盘只有⽇志写⼊成功事务才算提交成功这⾥的⽇志就是Redo Log。当发⽣宕机且数据未刷到磁盘的时候可以通过Redo Log来恢复保证ACID中的持久性这也是Redo Log的作⽤。undo日志保证事务的原子性 2.Redo Log的写⼊时机 当发⽣数据修改操作时追加重做⽇志已落盘数据对应的⽇志位置被记录为⼀个检查点检查点之前的数据被置为⽆效所以重做⽇志⽂件可以循环使⽤。以⼀个更新操作为例重做⽇志的写⼊过程与时机如下图所⽰ 使用Log Buffer的原因因为每次进⾏DML操作都会进⾏⼀次磁盘I/O这样会严重影响效率所以把⽇志统⼀写⼊内存中的Log Buffer根据刷盘策略统⼀进⾏落盘操作可以实 现⼀次磁盘I/O写⼊多条⽇志从⽽提升效率。 2.Redo Log的格式是怎样的 分析过程 1.在介绍RedoLog的格式之前先来分析⼀下RedoLog中需要记录哪些内容 (1)当进⾏DML操作时⾸先要修改内存中的数据⻚但是修改的数据有可能只是数据⻚中很少的⼀部分内容甚⾄有可能只修改了⼏个字节那么在RedoLog中是要记录整个数据⻚吗当然不是如果每次保存整个数据⻚的话就有太多的⽆⽤数据写⼊⽇志严重影响效率⽽且浪费空间 (2)为了节省空间提⾼效率RedoLog只记录被修改的内容⽐如当前的DML修改了哪个表空间、表空间中的哪个数据⻚数据⻚中多少偏移量处的值修改成了什么⽐如 # ⼀个例⼦ 1 号表空间中的⻚编号为 50 的数据⻚中偏移量为 1000 处的整型值修改为 100 在示例中明确了当前日志对应的文件要修改的起始位置要修改的长度和新值 (3)这样就可以⽤很⼩的⽇志记录当前对数据⻚所做的修改⼤⼤节省了空间 解答问题 1.RedoLog本质上只是记录了事务对数据库做了哪些修改修改操作包含多种场景⽐如对数据⾏、索引⻚的增删改对范围的修改与删除等等不同场景的 redo ⽇志定义了不同的类型但是绝⼤部分类型的 redo ⽇志都有下边这种通⽤的结构包括 (1)Type : ⽇志类型 1BTYE (2)Space ID : 操作所属的表空间 4BTYE (3)Page no : 操作的数据⻚在表空间中的编号 4BTYE (4)data ⽇志的内容⻓度不固定 衍⽣问题: 1.data 部分的具体内容是什么 data 部分⼜可以分为数据⻚中的偏移量修改内容的⻓度和具体的修改内容 3.RedoLog的类型分为哪些 分析过程: 查看RedoLog的类型最完整最直观的⽅式就是通过阅读源代码如下所⽰ /** file include/mtr0types.hMini-transaction buffer global typesCreated 11/26/1995 Heikki Tuuri*******************************************************/
// 省略...
/** name Log item types
The log items are declared byte so that the compiler can warn if val
and type parameters are switched in a call to mlog_write_ulint. NOTE!
For 1 - 8 bytes, the flag value must give the length also! { */
enum mlog_id_t {/** if the mtr contains only one log record for one page,i.e., write_initial_log_record has been called only once,this flag is ORed to the type of that first log record */MLOG_SINGLE_REC_FLAG 128,/** one byte is written */MLOG_1BYTE 1,/** 2 bytes ... */MLOG_2BYTES 2,/** 4 bytes ... */MLOG_4BYTES 4,/** 8 bytes ... */MLOG_8BYTES 8,/** Record insert */MLOG_REC_INSERT_8027 9,/** Mark clustered index record deleted */MLOG_REC_CLUST_DELETE_MARK_8027 10,/** Mark secondary index record deleted */MLOG_REC_SEC_DELETE_MARK 11,/** update of a record, preserves record field sizes */MLOG_REC_UPDATE_IN_PLACE_8027 13,
/*! Delete a record from a page */MLOG_REC_DELETE_8027 14,/** Delete record list end on index page */MLOG_LIST_END_DELETE_8027 15,/** Delete record list start on index page */MLOG_LIST_START_DELETE_8027 16,/** Copy record list end to a new created index page */MLOG_LIST_END_COPY_CREATED_8027 17,/** Reorganize an index page in ROW_FORMATREDUNDANT */MLOG_PAGE_REORGANIZE_8027 18,/** Create an index page */MLOG_PAGE_CREATE 19,/** Insert entry in an undo log */MLOG_UNDO_INSERT 20,/** erase an undo log page end */MLOG_UNDO_ERASE_END 21,/** initialize a page in an undo log */MLOG_UNDO_INIT 22,/** reuse an insert undo log header */MLOG_UNDO_HDR_REUSE 24,/** create an undo log header */MLOG_UNDO_HDR_CREATE 25,/** mark an index record as the predefined minimum record */MLOG_REC_MIN_MARK 26,/** initialize an ibuf bitmap page */MLOG_IBUF_BITMAP_INIT 27,
#ifdef UNIV_LOG_LSN_DEBUG/** Current LSN */MLOG_LSN 28,
#endif /* UNIV_LOG_LSN_DEBUG *//** this means that a file page is taken into use and the priorcontents of the page should be ignored: in recovery we must not
trust the lsn values stored to the file page.Note: its deprecated because it causes crash recovery problemin bulk create index, and actually we dont need to reset pagelsn in recv_recover_page_func() now. */MLOG_INIT_FILE_PAGE 29,/** write a string to a page */MLOG_WRITE_STRING 30,/** If a single mtr writes several log records, this logrecord ends the sequence of these records */MLOG_MULTI_REC_END 31,/** dummy log record used to pad a log block full */MLOG_DUMMY_RECORD 32,/** log record about creating an .ibd file, with format */MLOG_FILE_CREATE 33,/** rename a tablespace file that starts with (space_id,page_no) */MLOG_FILE_RENAME 34,/** delete a tablespace file that starts with (space_id,page_no) */MLOG_FILE_DELETE 35,/** mark a compact index record as the predefined minimum record */MLOG_COMP_REC_MIN_MARK 36,/** create a compact index page */MLOG_COMP_PAGE_CREATE 37,/** compact record insert */MLOG_COMP_REC_INSERT_8027 38,/** mark compact clustered index record deleted */MLOG_COMP_REC_CLUST_DELETE_MARK_8027 39,/** mark compact secondary index record deleted; this logrecord type is redundant, as MLOG_REC_SEC_DELETE_MARK isindependent of the record format. */MLOG_COMP_REC_SEC_DELETE_MARK 40,/** update of a compact record, preserves record field sizes */MLOG_COMP_REC_UPDATE_IN_PLACE_8027 41,/** delete a compact record from a page */MLOG_COMP_REC_DELETE_8027 42,
/** delete compact record list end on index page */MLOG_COMP_LIST_END_DELETE_8027 43,/*** delete compact record list start on index page */MLOG_COMP_LIST_START_DELETE_8027 44,/** copy compact record list end to a new created index page */MLOG_COMP_LIST_END_COPY_CREATED_8027 45,/** reorganize an index page */MLOG_COMP_PAGE_REORGANIZE_8027 46,/** write the node pointer of a record on a compressednon-leaf B-tree page */MLOG_ZIP_WRITE_NODE_PTR 48,/** write the BLOB pointer of an externally stored columnon a compressed page */MLOG_ZIP_WRITE_BLOB_PTR 49,/** write to compressed page header */MLOG_ZIP_WRITE_HEADER 50,/** compress an index page */MLOG_ZIP_PAGE_COMPRESS 51,/** compress an index page without logging its image */MLOG_ZIP_PAGE_COMPRESS_NO_DATA_8027 52,/** reorganize a compressed page */MLOG_ZIP_PAGE_REORGANIZE_8027 53,/** Create a R-Tree index page */MLOG_PAGE_CREATE_RTREE 57,/** create a R-tree compact page */MLOG_COMP_PAGE_CREATE_RTREE 58,/** this means that a file page is taken into use.We use it to replace MLOG_INIT_FILE_PAGE. */MLOG_INIT_FILE_PAGE2 59,/** Table is being truncated. (Marked only for file-per-table) *//* MLOG_TRUNCATE 60, Disabled for WL6378 *//** notify that an index tree is being loaded without writing
redo log about individual pages */MLOG_INDEX_LOAD 61,/** log for some persistent dynamic metadata change */MLOG_TABLE_DYNAMIC_META 62,/** create a SDI index page */MLOG_PAGE_CREATE_SDI 63,/** create a SDI compact page */MLOG_COMP_PAGE_CREATE_SDI 64,/** Extend the space */MLOG_FILE_EXTEND 65,/** Used in tests of redo log. It must never be used outside unit tests. */MLOG_TEST 66,MLOG_REC_INSERT 67,MLOG_REC_CLUST_DELETE_MARK 68,MLOG_REC_DELETE 69,MLOG_REC_UPDATE_IN_PLACE 70,MLOG_LIST_END_COPY_CREATED 71,MLOG_PAGE_REORGANIZE 72,MLOG_ZIP_PAGE_REORGANIZE 73,MLOG_ZIP_PAGE_COMPRESS_NO_DATA 74,MLOG_LIST_END_DELETE 75,MLOG_LIST_START_DELETE 76,/** biggest value (used in assertions) */MLOG_BIGGEST_TYPE MLOG_LIST_START_DELETE
};
// 省略...解答问题: RedoLog的类型根据数据操作的不同场景和对⽇志的优化⽅式有⼏⼗种之多总体可以分为 (1)⽤于数据⻚的⽇志类型⽐如对数据⻚的修改 (2)⽤于表空间⽂件的⽇志类型⽐如对表空间的修改 (3)提供额外信息的⽇志类型
