有空间与域名后怎么做网站,苏州市网站建设,推动品牌建设的网站,wordpress回复看内容文章目录 一、前言二、redo 日志1. redo 日志格式2. Mini-Transaction2.1 以组的形式写入 redo 日志2.2 Mini-Transaction #xff08;MTR#xff09;概念 3. redo 日志写入过程3.1 redo 日志缓冲区3.3 redo 日志写入 log buffer 4. redo 日志文件4.1 redo 日志刷盘机制4.2 r… 文章目录 一、前言二、redo 日志1. redo 日志格式2. Mini-Transaction2.1 以组的形式写入 redo 日志2.2 Mini-Transaction MTR概念 3. redo 日志写入过程3.1 redo 日志缓冲区3.3 redo 日志写入 log buffer 4. redo 日志文件4.1 redo 日志刷盘机制4.2 redo 日志文件组4.3 redo 日志文件格式 5. 相关的全局变量 三、Checkpoint四、补充1. binlog 和 redo log 的区别2. redo log 写入的可靠性 五、参考内容 一、前言
最近在读《MySQL 是怎样运行的》、《MySQL技术内幕 InnoDB存储引擎 》后续会随机将书中部分内容记录下来作为学习笔记部分内容经过个人删改因此可能存在错误如想详细了解相关内容强烈推荐阅读相关书籍 二、redo 日志
事务四大特性 ACID (原子性、一致性、隔离性、持久性)
原子性 (atomicity)事务要么成功要么失败不存在中间状态一致性 (consistency)事务将DB 从一种状态转变为另一种一直的状态在事务开始前和结束后DB的完整性约束没有被破坏。隔离性 (isolation)每个读写事务的对象对其他事物的操作对象能相互分离即该事务提交前对其他事务都不可见通常使用锁来实现持久性 (durability)事务一旦提交其结果就是永久性的
其中 D (持久性) 的是由 redo 日志来实现的 redo 日志由两部分组成一是内存中的重做日志缓冲redo log buffer是易失的而是redo 日志文件redo log file是持久的。 InnoDB 是以页为单位来管理存储空间的我们进行的增删改查操作本质上都是对页的操作而前面【MySQL03】【 Buffer Pool】 中提到过InnoDB 在真正访问页面时会先判断页在 Buffer Pool 中是否存在如果存在则直接操作 Buffer Pool 中的页否则将页从磁盘读取到 Buffer Pool 中再操作。而 Buffer Pool 中的页在被修改后并不会立刻刷新到磁盘此时就会造成 Buffer Pool 中的页与磁盘页的数据并不相同即脏页。而如果在一个事务提交后修改数据写到 Buffer Pool 中但是并未刷盘如果此时系统宕机内存数据全部丢失则会造成数据的不一致。
一个简单的做法是在事务提交前将所有的页面都刷新到磁盘不过该方案存在如下问题
刷新一个完整的页面太浪费了有时候仅仅修改了页面的一个字节也需要将整个页刷新到磁盘。随机IO刷新效率太低。一个事务可能包含很多语句即使一个语句也可能修改很多页面并且这些页面可能并不相邻在将这些页面刷新到磁盘的时候需进行很对随机IO。
因为上述问题InnoDB 并不是在事务提交时将所有页刷新到磁盘而是将修改的内容记录下来在合适的时机刷新到磁盘中。记录的并不是全量内容而是增量内容因此需要 double write 来保证写入的可靠性。比如某个事务将系统表空间第100号页面中偏移量为 1000 处的变量值从 1 改成2只需要记录 将系统表空间第100号页面中偏移量为 1000 处的变量值更新为2 当事务提交后就会将上述内容刷新到磁盘即使之后系统崩溃了重启之后按照记录内容重新更新数据页即可。上述内容被称为重做日志redo log使用重做日志有如下好处
redo 日志占用空间非常小在存储表空间ID、页号、偏移量以及需要更新的值时需要的存储空间很小。redo 日志是顺序写入磁盘的在事务执行过程中每执行一条语句就可能产生若干个 redo 日志这些日志是按照产生的顺序写入磁盘的即顺序IO。
所以 InnoDB 通过 Force Log at Commit 机制实现事务的持久性即当事务提交时必须先将该事务的所有日志写入到重做日志文件进行持久化待事务的提交操作完成才算完成。这里的日志指的是 重做日志其由两部分组成即 redo log 和 undo log。 redo log 用来保证事务的持久性; undo log 用来帮助事务回滚以及 MVCC 的功能。redo log 基本都是顺序写, 在 DB运行时不需要对 redo log 文件进行读取操作而 undo log 是需要进行随机读写。
为了确保每次日志都写入重做日志文件在每次将重做日志缓冲写入 redo log 后 InnoDB 都需要调用一次 fsync 来刷新文件缓冲区数据到磁盘中。InnoDB 允许设置非持久性的情况即当事务提交时日志不写入重做日志文件而是等待一个时间周期后再执行 fsync 操作借此可以提高DB性能但是宕机后可能会存在最新数据丢失。
1. redo 日志格式 具体字段如下
字段解释typeredo 日志的类型 占用 1 个字节space ID表空间IDpage number页号dataredo 日志的具体内容 在将一条记录插入到一个页面时需要更改的地方非常多如
表中有多少个索引一条Insert 语句就需要可能更新多少棵 BTree针对某一棵BTree即可能更新叶子节点页面也可能更新内存节点页面还可能创建新页面如页分裂可能更新 Page Directory 中的槽信息可能更新 Page Header 中各种页面统计信息等等
所以可能出现如下情况在数据页修改的过程中可能会出现很多不连续的修改如下图 InnoDB 设计了多种 redo 日志类型用于处理这种情况这部分不做过多介绍如有需要可以参考书中内容。 2. Mini-Transaction
2.1 以组的形式写入 redo 日志
在执行语句的过程中产生的 redo 日志被 InnoDB 划分为了若干个不可分割的组。比如
更新 Max Row ID 属性时产生的 redo 日志为一组,是不可分割的。向聚簇索引对应的 BTree 的页面中插入一条记录时产生的 redo 日志为一组是不可分割的。向某个二级索引对应的 BTree 的页面中插入一条记录时产生的 redo 日志是一组是不可分割的。 InnoDB 规定执行需要保证原子性的操作时所以必须以组的形式来记录 redo 日志在进行恢复时针对某个组中的 redo log 要么把全部的日志都恢复要么一条也不恢复。即 redo log 也存在自身的原子性。
这里存在两种情况 有些需要保证原子性的操作生成了多条 redo log InnoDB 会在一组的最后一条 redo log 后面加上一条特殊类型的redo 日志该类型的reod 日志名为 MLOG_MULTI_REC_END结构只有一个 type 字段对应十进制的数字31。在系统崩溃恢复的时候只有解析到类型为 MLOG_MULTI_REC_END 的 redo 日志时才认为解析到一组完整的redo 日志才会进行恢复否则直接放弃前面解析到的 redo 日志。 有些需要保证原子性的操作只生成一条 redo log 这种情况虽然也可以在 redo log 后面追加一条 MLOG_MULTI_REC_END 日志但是 InnoDB 设计的更加节约一些在上面的 redo log 通用日志格式的时候介绍过 redo log 第一个字段是 type, 表示 redo 日志的类型而这个字段实际占用 1 字节但实际上 redo log 日志的类型并没有那么多种所以其实使用 7位足以表示因此 type 字段的第一位可以用来表示是否是单一日志如下
2.2 Mini-Transaction MTR概念
InnoDB 将对底层页面进行一次原子访问的过程称为一个 Mini-Transaction (MTR)。即一个 MTR 可以包含一组 redo 日志在进行崩溃恢复时需要把这一组 redo 日志作为一个不可分割的整体来处理。
即一个事务可以包含多个语句一个语句可以包含多个 MTR一个 MTR 可以包含多条 redo log。
3. redo 日志写入过程
InnoDB 将 MTR 生成的 redo 日志放在了大小为 512 字节的页中由于 redo log block的大小和磁盘扇区大小一样都是512 字节因此重做日志的写入可以保证原子性不需要 double writer 技术这里的redo 日志页跟之前提到表空间中的数据页并不相同为了方便区分我们将 redo 日志 写入的页称为 block。真正存储redo日志的部分是 log block bodylog block header 和 log block trailer 存储的是一些管理信息。一个 redo log block 示意图如下 3.1 redo 日志缓冲区
在【MySQL03】【 Buffer Pool】 中提到过 Buffer Pool 的概念。同理在写入 redo 日志时也不能直接写入到磁盘中实际上在服务器启动的时候就向操作系统申请了一片连续的内存空间用于作为 redo log buffer (redo 日志缓冲区), 也可以称为 log buffer这片连续的内存空间被划分为若干个连续的 redo log block 如下图
3.3 redo 日志写入 log buffer
向 log buffer 中写入redo 日志的过程是顺序写入的也就是先往前面的 block 中写当该 block 没有空闲空间后再写入下一个 block 中因此当 log buffer 写入 redo 日志时就需要一个全局变量 log_free 记录应该从哪个 block 的哪个偏移量写入如下
一个 MTR 执行过程中可能产生若干条 redo 日志这些redo 日志是一个不可分割的组所以并不是每生成一条 redo 日志就将其插入到 log buffer 中而是将每个 MTR 运行过程中产生的日志先暂存到一个地方当 MTR 结束后再将过程中产生的一组 redo 日志全部复制到 log buffer中。
另外需要注意的是因为事务是可以并发执行的每当一个 MTR 完成就会将该MTR 生成的 redo 日志复制到 log buffer 中因此对于不同事务的 MTR 对应的 redo 日志可能是交替写入 log buffer 的。
4. redo 日志文件
4.1 redo 日志刷盘机制
redo 日志会先被写入到 内存中的 log buffer 中在合适的时机再将 log buffer 中的数据刷新到磁盘中刷盘时机如下
log buffer 空间不足log buffer 大小通过 innodb_log_buffer_size 指定当 log buffer 使用量超过50% 时会触发刷盘机制事务提交时会触发刷盘。将脏页刷新到磁盘前会先保证将该脏页对应的 redo 日志刷新到磁盘中由于 redo 日志是顺序写入的所以将某个脏页对应的redo 日志刷新到磁盘时也会保证将其之前产生的 redo 日志刷新到磁盘后台线程大约每秒一次将log buffer 刷新到磁盘正常关闭服务器时checkpoint 时。
4.2 redo 日志文件组
redo 日志文件组是一个逻辑上的概念并没有一个实际存储的物理文件来表示 redo 日志文件组(log group)。InnoDB 默认情况下是存在多个 redo 日志文件的(默认为 ib_logfile0 和 ib_logfile1 两个文件)这多个 redo 日志文件被称为 redo 日志文件组。当一个 redo log 写满后会选择下一个 redo 日志文件(如果循环写入可能会造成追尾的情况 InnoDB 通过 Checkpoint 机制来处理这种清理)如下
4.3 redo 日志文件格式
redo 日志文件本质就是将 log buffer 刷新到磁盘文件中因此redo 日志文件也是由若干个 512 字节大小 block 组成。在 redo 日志文件组中每个文件的大小、格式都一样
前 2048 个字节即 2KB前4个block用来存储一些管理信息2048 个字节往后存储 log buffer 中的镜像。
redo 日志文件前2KB存储的的内容如下
名称大小字节解释log file header512记录该 redo 日志文件的一些整体属性checkpoint1512记录checkpoint信息空512未使用checkpoint2512记录checkpoint信息
需要注意的是
对于上述这些信息仅 redo 日志文件组的中的第一个 redo 日志文件保存这些信息其余的文件仅仅保留上述空间而不保留文件信息同时因为保存了上述信息所以 redo 日志文件的写入并非是完全有序的。 如下图在同一个redo 日志文件组由于 ib_logfile01 是日志文件组中的第一个文件所以其前2KB 存储相关信息 而 ib_logfile1 前2KB 仅仅保留空间而不保存文件信息
5. 相关的全局变量 log sequence number : InnoDB 中存在一个名为 log sequence number lsn 的全局变量用来记录当前已经写入的 redo 日志量其初始值是8704初始值没有什么意义仅仅就是一个数字单位是字节也就是说每写入1字节的 redo 日志lsn 就会加1。每一组 MTR 生成的 redo 日志都有唯一的 lsn 值与其对应lsn 值越小说明 redo 日志产生的越早。 在MTR 结束时还会将MTR 执行过程中修改过的页面加入到 Buffer Pool 的 flush 链表中当第一次修改某个已经加载到 Buffer Pool 中的页面时就会把这个页面对应的控制块插入到 flush 链表的头部之后在修改该页时如果页面已经存在在 flush 链表中则不会再次插入也就是说flush 链表中的脏页是按照页面第一次修改时间进行排序的在这个过程中会在缓冲页对应的控制块中记录两个关于页面何时修改的属性 oldest_modification : 第一希修改 buffer pool 中某个缓冲页时就将修改该页面的MTR开始时对应的lsn 值写入这个属性newest_modification : 每修改一次页面就会将该修改页面的 MTR结束时对应的值写入这个属性。也就是说该属性表示页面最近一次修改后对应的 lsn 的值。 总的来说flush 链表中的脏页是按照页面第一次修改时间进行排序的也就是按照 oldest_modification 属性 代表的lsn 的值进行排序被多次更新的页面不会插入到 flush 链表中但是会更新 newest_modification 属性的值 buf_next_to_write : redo 日志是先写入到 log buffer 中之后才会被刷新到磁盘的 redo 日志文件中并且由于 redo log block的大小和磁盘扇区大小一样都是512 字节因此重做日志的写入可以保证原子性不需要 double writer 技术。InnoDB 中存在一个buf_next_to_write 的全局变量用来标记当前 log_buffer 中已经有哪些日志被刷新到磁盘了。 flushed_to_disk_lsn : lsn 表示系统写入的redo 日志量这包括了写入到 log buffer 但是没有刷新到磁盘的redo 日志。因此 InnoDB还存在一个 flushed_to_disk_lsn 的全局变量用来记录刷新到磁盘的 redo 日志量。在系统启动时flushed_to_disk_lsn 和 lsn 的初始值都是8704在系统运行过程中由于部分 log buffer 没有刷新到磁盘会导致二者差异化。
三、Checkpoint
由于 redo 日志文件组的容量是有限的所以不得不循环使用 redo 日志文件组的文件但这需要判断redo 日志文件组中的哪些内容没有存在的必要redo 日志只是为了在系统崩溃后恢复脏页用的因此判断 redo 日志占用磁盘是否可以被覆盖的一句就是它对应的脏页是否已经被刷新到磁盘中。
InnoDB 存在一个全局变量 checkpoint_lsn 用来表示当前系统中可以被覆盖的 redo 日志的总览是多少该变量的初始值也为 8704。当 脏页被刷新到磁盘上就可以执行一个增加 checkpoint_lsn 的操作这个过程称为执行一次 checkpoint。 InnoDB 中存在后台线程将脏页刷新到磁盘这里的 刷新到磁盘 和 执行一次 chekcpoint 是两回事一般来说脏页的刷新和 执行一次 checkpoint 是在不同线程上执行的并不是说每次有脏页刷新就要去执行一次 checkpoint。 执行一次 checkpoint 可以分为两个步骤 计算当前系统中可以被覆盖的redo 日志对应的 lsn 值最大是多少 redo 日志可以覆盖的前提是他对应的脏页被刷新到磁盘中因此只要我们计算出当前系统最早修改的脏页对应的 oldest_modification 值那么凡是系统在 lsn 值小于该节点的 oldest_modification 值时产生的redo 日志都可以被覆盖掉。我们把该脏页的 oldest_modification 赋值给 checkpoint_lsn。 flush 链表的尾节点就是 系统中最早修改的脏页其 oldest_modification 的值可以获取并赋值给 checkpoint_lsn如果 redo 日志对应的 lsn 值小于 checkpoint_lsn 时就可以被覆盖掉。 将 checkpoint_lsn 与对应的 redo 日志文件组偏移量以及此次 checkpoint 的编号写到日志文件的管理信息checkpoint1 和 checkpoint2 当 checkpoint_no 是奇数时写入到 checkpoint2是偶数时写入到 checkpoint1中。 InnoDB 维护了一个 checkpoint_no 变量用来统计系统执行了多少次 checkpoint每执行一次 checkpoint该变量的值就加1
注意一般情况下都是后台线程对 LRU 链表和 flush 链表进行刷盘操作因为刷盘操作比较慢不想影响用户线程的处理请求。但是如果当前系统修改页面的操作过于频繁就会导致写 redo 日志的操作十分频繁系统 lsn 值增长过快。如果后台线程的刷盘操作不能将脏页快速刷出系统将无法执行 checkpoint 可能就需要用户线程从 flush 链表中把那些最早修改的脏页同步刷新到磁盘。这样这些脏页对应的 redo 日志就没用了就可以执行 checkpoint。
四、补充
1. binlog 和 redo log 的区别
二进制日志记录所有与 Mysql DB有关的日志记录不管是什么存储引擎而 重做日志是 InnoDB 特有的仅记录 InnoDB 存储引擎的事务日志。二进制日志记录的是关于一个事务的具体操作内容即逻辑日志而 重做日志记录的是每个页的更改的物理情况二进制日志文件仅在事务提交前进行提交即只写入磁盘一次无论事务多大。而在事务进行过程中重做日志条目会不断写入到重做日志文件中。二进制日志写入后不会删除会一直存放在磁盘上用于主从同步或者数据恢复因此可能会存在磁盘被而二进制日志占满的情况。而 redo log 目的是为了保证数据写入的可靠性以及效率提高重做日志文件是可复用的因此不会存在磁盘占用过多的情况
2. redo log 写入的可靠性
由于 redo log block 的大小和磁盘扇区大小一样都是512 字节因为扇区是写入的最小单位所以可以保证写入是必定成功的。因此在重做日志的写入过程中不需要有 doublewrite。
五、参考内容
书籍《MySQL是怎样运行的——从根儿上理解MySQL》、《MySQL技术内幕 InnoDB存储引擎 》
如有侵扰联系删除。 内容仅用于自我记录学习使用。如有错误欢迎指正
