14_MySQL事务日志

已于 2023-01-29 15:34:47 修改
阅读量102 收藏
点赞数 1
分类专栏： # 高级篇（Linux) 文章标签： mysql 数据库 java
于 2022-10-22 21:51:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_48083892/article/details/127455369
版权

MySQL事务日志

事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？

  • 事务的隔离性由锁机制实现。
  • 而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
    • REDO LOG 称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。
      一个事务中会涉及到多个DML操作，操作中修改的内容首先针对的内存层面，加载进内存中的数据页中的数据；此时数据还没有及时的更新到磁盘中，而真正将数据刷到磁盘中才称为持久化。因此为了保证内存中修改的数据一定可以写进磁盘，就将内存中修改数据记录到Redo日志中，如果出现服务器宕机，确保可以从日志文件中将数据进行恢复
    • UNDO LOG 称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。
      在这里插入图片描述

在这里插入图片描述

1. redo日志

在这里插入图片描述

1.1 为什么需要REDO日志

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

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

那么如何保证这个持久性呢？一个简单的做法：在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘，但是这个简单粗暴的做法有些问题

在这里插入图片描述

另一个解决的思路：我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以我们其实没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘，只需要把修改了哪些东西记录一下就好。比如，某个事务将系统表空间中第10号页面中偏移量为100处的那个字节的值1改成2。我们只需要记录一下：将第0号表空间的10号页面的偏移量为100处的值更新为 2 。

在这里插入图片描述
在这里插入图片描述

1.2 REDO日志的好处、特点

1. 好处

  • redo日志降低了刷盘频率
  • redo日志占用的空间非常小

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

2. 特点

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

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

1.3 redo的组成

Redo log可以简单分为以下两个部分：

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

在这里插入图片描述
在这里插入图片描述

参数设置：innodb_log_buffer_size：

redo log buffer 大小，默认16M，最大值是4096M，最小值为1M。

mysql> show variables like '%innodb_log_buffer_size%';
+------------------------+----------+
| Variable_name          |    Value |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+
  • 重做日志文件 (redo log file)，保存在硬盘中，是持久的。

在这里插入图片描述
在这里插入图片描述

1.4 redo的整体流程

以一个更新事务为例，redo log 流转过程，如下图所示：
在这里插入图片描述

第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝

第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值

第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式

第4步：定期将内存中修改的数据刷新到磁盘中

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

1.5 redo log的刷盘策略

在这里插入图片描述

redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以一定的频率刷入到真正的redo log file 中。这里的一定频率怎么看待呢？这就是我们要说的刷盘策略。
在这里插入图片描述

redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如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.6 不同刷盘策略演示

1. 流程图

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2.举例

在这里插入图片描述
在这里插入图片描述

1.7 写入redo log buffer过程

1. 补充概念：Mini-Transaction

在这里插入图片描述

一个事务可以包含若干条语句，每一条语句其实是由若干个mtr组成，每一个mtr又可以包含若干条redo日志

在这里插入图片描述

2. redo 日志写入log buffer

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

不同的事务可能是并发执行的，所以事务T1、事务T2之间的mtr可能是交替执行的。每当一个mtr执行完成时，伴随该mtr生成的一组redo日志就需要被复制到log buffer中，也就是说不同事务的mtr可能是交替写入log buffer的，我们画个示意图(为了美观，我们把一个mtr中产生的所有的redo日志当作一个整体来画):

在这里插入图片描述
在这里插入图片描述

3. redo log block的结构图

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

1.8 redo log file

1. 相关参数设置
  • 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个。
mysql> show variables like 'innodb_log_files_in_group';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_log_files_in_group | 2     |
+---------------------------+-------+
#ib_logfile0
#ib_logfile1
  • 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。
mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name        | Value    |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+

根据业务修改其大小，以便容纳较大的事务。编辑my.cnf文件并重启数据库生效，如下所示

[root@localhost ~]# vim /etc/my.cnf
innodb_log_file_size=200M

在这里插入图片描述

2. 日志文件组

在这里插入图片描述

在这里插入图片描述

3. checkpoint

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1.9 redo log小结

在这里插入图片描述

2. Undo日志

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

2.1 如何理解Undo日志

事务需要保证原子性，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如：

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

以上情况出现，我们需要把数据改回原先的样子，这个过程称之为回滚，这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。

在这里插入图片描述

2.2 Undo日志的作用

  • 作用1：回滚数据
    在这里插入图片描述

  • 作用2：MVCC（详情看第16章）
    在这里插入图片描述

2.3 undo的存储结构

1. 回滚段与undo页

InnoDB对undo log的管理采用段的方式，也就是回滚段（rollback segment）。每个回滚段记录了1024个undo log segment，而在每个undo log segment段中进行undo页的申请。

  • 在 InnoDB1.1版本之前 （不包括1.1版本），只有一个rollback segment，因此支持同时在线的事务限制为 1024 。虽然对绝大多数的应用来说都已经够用。
  • 从1.1版本开始InnoDB支持最大 128个rollback segment ，故其支持同时在线的事务限制提高到了 128*1024 。
mysql> show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_undo_logs |   128 |
+------------------+-------+

在这里插入图片描述
undo重用：
在这里插入图片描述

2. 回滚段与事务

  1. 每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。

  2. 当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。

  3. 在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。

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

在这里插入图片描述

  1. 当事务提交时，InnoDB存储引擎会做以下两件事情：
    • 将undo log放入列表中，以供之后的purge操作
    • 判断undo log所在的页是否可以重用，若可以分配给下个事务使用
3. 回滚段中的数据分类

  1. 未提交的回滚数据(uncommitted undo information)

  2. 已经提交但未过期的回滚数据(committed undo information)

  3. 事务已经提交并过期的数据(expired undo information)

在这里插入图片描述

2.4 undo的类型

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

  • insert undo log
  • update undo log

在这里插入图片描述

2.5 undo log的生命周期

1. 简要生成过程

在这里插入图片描述
在这里插入图片描述

只有Buffer Pool的流程：

在这里插入图片描述

有了Redo Log和Undo Log之后：

在这里插入图片描述
在这里插入图片描述

2. 详细生成过程

在这里插入图片描述

当我们执行INSERT时：

begin; 
INSERT INTO user (name) VALUES ("tom");

在这里插入图片描述

当我们执行UPDATE时：

UPDATE user SET id=2 WHERE id=1;

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3. 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的数据删除

4. undo log的删除

  • 针对于insert undo log

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

  • 针对于update undo log

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

在这里插入图片描述

2.6 小结

在这里插入图片描述

undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。

redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程。

听*雨声
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
一文带你了解MySQL之Log Buffer
Multis
05-05 1358
讲解了Redo Log和MySQL InnoDB Log Buffer的工作原理，通过流程图的方式来说明Redo Log三种刷盘策略的工作流程，偏理论的知识，内容比较少也很好理解
MySQL~Redo刷盘策略、LogBuffer缓存池和LogFile日志文件理解
zxc的博客
05-11 2387
文章目录刷盘策略不同刷盘策略演示Redo log buffer缓存区Redo log file日志文件总结 刷盘策略 Innodb在写Redo日志的时候，是先写入redo log buffer 中，然后再按照一定频率刷新到redo log file中。 这里的 一定频率 有多个选择，这些选择对应的就是不同的刷盘策略. 这里的刷盘不是指将内存中的数据刷新到磁盘，而是指从Redo日志位于内存中的缓冲区（redo log buffer）刷新到位于磁盘中的文件区（redo log file）. redo
Mysql修改innodb_page_size参数
luomo0203的博客
02-08 3518
指定InnoDB表空间的页面大小。可以以字节或千字节为单位指定值。例如，16KB的页面大小值可以指定为16384、16KB或16k。innodb_page_size只能在初始化MySQL实例之前配置，之后不能更改。如果未指定值，则使用默认页面大小初始化实例。参见第15.8.1节“InnoDB启动配置”。对于32KB和64KB页面大小，最大行长度约为16000字节。ROW_FORMAT=当innodb_page_size设置为32KB或64KB时，不支持COMPRESSED。
总结 mysql 的所有 buffer，一网打尽就这篇了！
m0_73311735的博客
10-19 1350
好了，关于 innodb buffer 们介绍完了，我们来总结一下：buffer pool，缓存数据页，避免频繁地磁盘交互，内部利用定制的 LRU 来淘汰缓存页，LRU分老年代和新生代。change buffer，用于二级非唯一索引的新增、修改或删除操作，当 buffer pool 没有数据的时候，不需要加载数据页到缓冲池中，而是通过 change buffer 来记录此变更，减少随机 I/O。log buffer，用于 redo log 的缓冲，减少 I/O，批处理减少系统调用。
Mysql日志：二进制日志、事务日志（redo log、undo log）、快照读和当前读、共享锁和排他锁、Log Buffer
haoranhaoshi的博客
11-19 788
二进制日志 Mysql的binlog是二进制日志文件。包括日志索引文件（后缀为.index）和日志文件（后缀为.00000*）。日志索引文件记录日志文件。日志文件记录数据定义和写方式的数据操作语句。（数据定义、数据操作：参考：https://blog.csdn.net/haoranhaoshi/article/details/109804069）参考：https://blog.csdn.net/lzhcoder/article/details/88814364 事务日志 innodb事务日志包括und
详解 Mysql 事务和Mysql 日志
09-08
主要介绍了详解 Mysql 事务和Mysql 日志的相关资料，文中讲解非常细致，代码帮助大家更好的理解和学习，感兴趣的朋友可以了解下
MYSQL中事务、日志、锁
最新发布
02-22
MYSQL中事务、日志、锁
MySQL日志管理详解
02-01
错误日志查询日志慢查询日志二进制日志中继日志事务日志滚动日志说明：在对应的数据目录中，以主机名+.err命名的文件，错误日志记录的信息类型：记录了服务器运行中产生的错误信息记录了服务在启动和停止是所产生的...
解决Mysql收缩事务日志和日志文件过大无法收缩问题
09-09
主要介绍了解决Mysql收缩事务日志和日志文件过大无法收缩问题,非常不错，具有参考借鉴价值，需要的朋友可以参考下
MySQL中的Buffer pool，以及各种buffer
qq_43325216的博客
01-19 1239
buffer pool是一块内存区域，是一种“降低磁盘访问机制”，buffer pool缓存数据表和索引数据，吧磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。buffer pool也是以页为存储单位（与磁盘中数据页索引页单位一样，默认大小16K），buffer pool底层采用链表的数据结构管理page。所有数据页的读写操作都要通过buffer pool进行。
MySQL（八）：InnoDB 日志缓冲区（Log Buffer）
码客
03-08 7538
1、简述 当在MySQL中对InnoDB表进行更改时，这些更改首先存储在InnoDB日志缓冲区的内存中，然后写入通常称为重做日志（redo logs）的InnoDB日志文件中。 日志缓冲区是内存存储区域，用于保存要写入磁盘上的日志文件的数据。日志缓冲区大小由innodb_log_buffer_size 变量定义，默认大小为16MB。 日志缓冲区的内容定期刷新到磁盘。较大的日志缓冲区可以运行大型事...
mysql innodb log buffer size和 innodb buffer pool size设置
trigfj的博客
11-15 465
mysql innodb log buffer size和 innodb buffer pool size设置
MySQL：redo log buffer
OceanStar的博客
12-22 1782
什么是redo log buffer 我们平时执行完增删改之后，要写入磁盘的redo log，其实应该是先进入redo log block这个数据结构里去的，然后在进入磁盘文件里： 也就是说redo log先通过内存缓存之后，再进入到磁盘文件里去的。这里涉及到了一个新的组件，redo log buffer，它是MySQL专门涉及用来缓存redo log写入的。 这个redo log buffer其实就是MySQL在启动的时候，跟操作系统申请的一块连续内存空间，和buffer pool（申请之后划分了N个空
必须了解的mysql三大日志-binlog、redo log和undo log
良月柒
09-08 2459
程序员的成长之路互联网/程序员/技术/资料共享关注阅读本文大概需要 5.5 分钟。来自：https://juejin.im/post/6860252224930070536日志是my...
MySQL重做日志缓冲 - Redo log Buffer
weixin_39997438的博客
08-01 1825
1、前提概念：Mini-Transaction InnoDB有两个非常重要的日志：undo log、redo log （1）通过undo log可以看到数据较早版本，实现MVCC，或回滚事务等功能。 （2）通过redo log用来保证事务持久性。 Mini-Transaction是用来实现InnoDB的物理逻辑日志的写入和页恢复的。通过Mini-Transaction来保证并发事务操作和数据库异常时页的一致性。换言之，Mini-Transaction主要用于innodb redo log和undo log写
点点滴滴 之 Mysql中的Change Buffer和Log Buffer
在这个数字革命的时代，我们将引领您穿越去中心化、智能合约、加密货币以及分布式应用程序的世界。无论您是初学者还是经验丰富的区块链开发者，我们都致力于为您提供有价值的信息和见解。
11-07 483
文章目录`Change Buffer`的作用`Change Buffer`图解`Change Buffer`的大小`Change Buffer`中的内容写入硬盘Log Buffer我的个人博客，更易阅读 Change Buffer的作用 Change Buffer是用来缓存那些在Buffer Pool中没有的数据页中的二级缓存。Insert,update,delete等操作会触发缓存动作，并且在...
MySQL 之 InnoDB引擎 Log Buffer
心有猛虎 细嗅蔷薇
04-30 1751
Log Buffer(日志缓冲区)是一块内存区域用来保存要写入磁盘上的日子文件的数据。 Log Buffer的大小由innodb_log_buffer_size变量定义。默认大小为16MB。Log Buffer的内容会定期刷到磁盘上。大的Log Buffer让较大事务能够运行，而无需在事务提交之前将redo log中的数据写入磁盘。 因此，如果有DML操作并且会影响很多行这样是事务，增加日志缓冲...
MySQL中redo日志
linuxheik的专栏
03-14 6199
MySQL中redo日志  数据库 重做日志用来实现事务的持久性，即ACID中的D，由两部分组成： 一是内存中的重做日志缓冲(redo log buffer)  易丢失 二是重做日志文件(redo log file) 持久的 InnoDB是事务的存储引擎，其通过Force Log at Commit 机制实现事务的持久性，即当事务提交commit时，必须先将事务的所有日志
mysql原子性通过什么实现_mysql事务的实现原理
06-11
具体地说，MySQL将事务中所有的操作记录在一个事务日志（transaction log）中。当事务提交时，MySQL会将日志中的所有操作一次性写入磁盘。如果在事务执行过程中出现故障，MySQL可以使用日志中的信息来回滚事务，使得...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值