MySQL基础(三十三)MySQL事务日志

news2024/11/27 3:45:28

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

  • 事务的隔离性由 锁机制 实现。
  • 而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
    • REDO LOG 称为 重做日志 ,提供再写入操作,恢复提交事务修改的页操作,用来保证事务的持久性。
    • UNDO LOG 称为 回滚日志 ,回滚行记录到某个特定版本,用来保证事务的原子性、一致性。

有的DBA或许会认为 UNDO 是 REDO 的逆过程,其实不然。

1. redo日志

1.1 为什么需要REDO日志

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

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

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

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

1.2 REDO日志的好处、特点

1. 好处

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

2. 特点

  • redo日志是顺序写入磁盘的
  • 事务执行过程中,redo 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 logfile,对 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. 流程图
在这里插入图片描述

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

1.7 redo log file

1. 相关参数设置

  • innodb_log_group_home_dir :指定 redo log 文件组所在的路径,默认值为 ./,表示在数据库的数据目录下。MySQL的默认数据目录( var/lib/mysql )下默认有两个名为 ib_logfile0ib_logfile1 的文件,log buffer中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志文件位置还可以修改。

  • innodb_log_files_in_group:指明redo log file的个数,命名方式如:ib_logfile0,iblogfile1…iblogfilen。默认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. 日志文件组

在这里插入图片描述
总共的redo日志文件大小其实就是: innodb_log_file_size × innodb_log_files_in_group

采用循环使用的方式向redo日志文件组里写数据的话,会导致后写入的redo日志覆盖掉前边写的redo日志?当然!所以InnoDB的设计者提出了checkpoint的概念。

3. checkpoint
在这里插入图片描述
如果 write pos 追上 checkpoint ,表示日志文件组满了,这时候不能再写入新的 redo log记录,MySQL 得停下来,清空一些记录,把 checkpoint 推进一下。
在这里插入图片描述

2. Undo日志

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

2.1 如何理解Undo日志

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

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

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

2.2 Undo日志的作用

  • 作用1:回滚数据
  • 作用2:MVCC

2.3 undo的存储结构

1. 回滚段与undo页

InnoDB对undo log的管理采用段的方式,也就是 回滚段(rollback segment) 。每个回滚段记录了1024undo 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 |
    +------------------+-------+
    

2. 回滚段与事务

  1. 每个事务只会使用一个回滚段,一个回滚段在同一时刻可能会服务于多个事务。
  2. 当一个事务开始的时候,会制定一个回滚段,在事务进行的过程中,当数据被修改时,原始的数据会被复制到回滚段。
  3. 在回滚段中,事务会不断填充盘区,直到事务结束或所有的空间被用完。如果当前的盘区不够用,事务会在段中请求扩展下一个盘区,如果所有已分配的盘区都被用完,事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
  4. 回滚段存在于undo表空间中,在数据库中可以存在多个undo表空间,但同一时刻只能使用一个undo表空间。
  5. 当事务提交时,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的逆过程。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/529164.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

深度学习之神经网络是如何自行学习的?

大家好,我是带我去滑雪! 深度学习算法是一种神经网络,而神经网络就是数据结构的图形结构,函数集的运算是向量和矩阵运算,调整函数集的参数需要使用微分和偏微分来找出最优解。深度学习可以通过几何学来进行解释&#x…

Excel的“升级版本”, 终于在2023年找到,替代Office包里的Access

Access的用户基数很大 首先,你要明白的是,Access是一款办公软件,其次才是一个数据库! 之所以一直以来被微软放在Office的包里,没有被淘汰,是因为Access在Excel处理大数据时崩溃的时候,面向很多…

本机连接aws的ec2时报错:所选用户的用户密钥未在远程主机上注册

引言 由于工作的需要,所以需要去学习下AWS相关的知识,所以自己注册了一个AWS的账号去进行学习。 问题发现 按照启动ec2实例的步骤:选择镜像->选择系统配置->配置密钥对->配置安全组->设置存储卷大小->启动实例 在上述操作…

237:vue+openlayers绘制多边形,生成geojson数据,计算出面积

第237个 点击查看专栏目录 本示例的目的是介绍演示如何在vue+openlayers中绘制多边形形,利用Geojson的writeFeatures,来生成geojson格式的数据,然后使用turf.area来计算面积。这里面着重解决了在3857的坐标系下,将geojson文件的坐标转化为4326的状态。 直接复制下面的 vue…

短视频矩阵源码系统

短视频矩阵源码系统开发要则: 1. 需求分析:对短视频平台的需求进行全面分析,确立系统开发目标和方向。 2. 技术选型:选用最适合的技术开发短视频矩阵系统,如前端框架、数据库、服务器等。 3. 系统设计:按…

EBAZ4205踩坑记录

这块ZYNQ-7000的二手板子很经典,最早在2019年被人发现。板子资源还是不错的,共引出了3*14个PL侧的IO,可用来研究PL、PS-PL交互,学习PS侧SDK,Linux开发。唯一的遗憾是Bank电压固定为3.3V,没法玩LVDS。 参考…

golang中的websocket,使用wireshark抓包

websocket 是一个长连接协议&#xff0c;全双工通信&#xff0c;主要应用在及时通信&#xff1a;实时聊天&#xff0c;游戏&#xff0c;在线文档等等。 简单示例 客户端 <!DOCTYPE html> <html lang"en"><head><meta charset"UTF-8&quo…

分支语句和循环语句

控制语句&#xff1a;用于控制程序的执行流程&#xff0c;以实现程序的各种结构方式&#xff0c;它们由特定的语句定义符组成&#xff0c;C语言有9种控制语句&#xff0c;可分为三类&#xff1a; 条件判断语句也叫分支语句&#xff1a;if语句&#xff0c;switch语句&#xff1b…

【基础算法】贪心算法基础

系列综述&#xff1a; &#x1f49e;目的&#xff1a;本系列是个人整理为了秋招算法的&#xff0c;整理期间苛求每个知识点&#xff0c;平衡理解简易度与深入程度。 &#x1f970;来源&#xff1a;材料主要源于代码随想录进行的&#xff0c;每个算法代码参考leetcode高赞回答和…

对SRC逻辑漏洞挖掘的思考

对SRC逻辑漏洞挖掘的思考 1.限制购买逻辑漏洞一人一单限制差价活动购买限制 2.支付类逻辑漏洞3.接口未授权逻辑漏洞4.越权类逻辑漏洞5.修改返回包进入后台6.任意用户注册7.重置任意用户 1.限制购买逻辑漏洞 一人一单限制 很多厂商都会搞一些活动&#xff0c;在享受优惠的时候…

微服务架构及工作原理!

在移动计算时代&#xff0c;应用程序开发人员应该能够快速部署操作并进行更改&#xff0c;而无需重新部署整个应用程序。结果&#xff0c;它导致了一种称为“微服务”的构建软件的新方法。 微服务是应用程序中独立的小部分&#xff0c;每个部分都完成自己的工作并通过API相互通…

Dubbo学习笔记

目录 简介 Dubbo高可用 集群容错 服务治理 Dubbo线程IO模型 源码层面 Java SPI 的问题 源码解析 简介 Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架&#xff0c;可以和Spring框架无缝集成。 Dubbo提供了…

主流总线通信和系统接口技术

一、关于现场控制总线 现场总线是自动控制领域的计算机局域网&#xff0c;应用在生产现场&#xff0c;在微机测控设备之间实现双向、串行、多节点数字通信&#xff0c;是一种开放式、数字化、多点通信的底层控制网络。 现场总线具有较高的测控能力指数 得益于仪表的微机化&am…

C++实现闭散列/开放定址法

前言 哈希冲突是无法避免的&#xff0c;只能尽可能的减少冲突的可能性&#xff0c;通常我们可以设计适合的哈希函数。但是&#xff0c;哈希冲突还是会发生&#xff0c;那我们如何解决呢&#xff1f; 我们可以使用闭散列/开放定址法的方法&#xff0c;解决哈希冲突 文章目录 前…

世界超高清大会发布重大技术成果:博冠自主创新推动8K摄像机攻关

一、世界超高清大会背景介绍&#xff1a; 近日&#xff0c;由工业和信息化部、国家广播电视总局、中央广播电视总台、广东省人民政府主办的2023世界超高清视频产业发展大会在广州越秀国际会议展览中心盛大召开。自2018年创办以来&#xff0c;大会已成功举办四届&#xff0c;成…

第08讲:搭建 SkyWalking 源码环境,开启征途

搭建 SkyWalking 源码环境 下载 SkyWalking 源码 执行 git clone 命令从 GitHub下载 SkyWalking 源码&#xff0c;如下所示 &#xff1a; git clone gitgithub.com:apache/skywalking.git 切换分支 等待 clone 完成之后&#xff0c;我们通过命令行窗口进入 SkyWalking 源码根…

SSM 三大框架原理、核心技术,运行流程讲解

作者:arrows 来源:https://www.cnblogs.com/arrows/p/10537733.html 一、Spring部分 1、 Spring的运行流程 第一步&#xff1a;加载配置文件ApplicationContext ac new ClassPathXmlApplicationContext(“beans.xml”); &#xff0c;ApplicationContext接口&#xff0c;它由…

存储卡目录变成未知文件?这些技巧能让你恢复数据!

当存储卡的目录变成未知文件时&#xff0c;我们无法直接访问存储卡中的数据。但是&#xff0c;这并不意味着这些数据永远无法恢复。以下是几种可能恢复存储卡数据的方法&#xff1a; 使用数据恢复软件。从互联网上下载并安装专业的数据恢复软件这些软件可以扫描存储卡&#xf…

分布式接口幂等性设计实现

面对分布式架构和微服务复杂的系统架构和网络超时服务器异常等带来的系统稳定性问题&#xff0c;分布式接口的幂等性设计显得尤为重要。本文简要介绍了几种分布式接口幂等性设计实现&#xff0c;包括Token去重机制、乐观锁机制、数据库主键和状态机实现等&#xff0c;以加深理解…

面板安全增强,网站支持反向代理设置,1Panel开源面板v1.2.0发布

2023年5月15日&#xff0c;现代化、开源的Linux服务器运维管理面板1Panel正式发布v1.2.0版本。 在这一版本中&#xff0c;1Panel着重增强了安全方面的功能&#xff0c;包括安全入口访问、面板SSL设置、网站密码访问等&#xff0c;同时网站新增支持反向代理设置&#xff0c;并带…