Undo日志文件的产生和使用

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Undo 日志 比如A有200块钱, B有50 块钱,现在A要给B转100块” 。 (1)  开始事务 T1 (假设T1是个事务的内部编号) (2)  A余额 = A余额 -100 (3)  B余额 = B余额 + 100 (4)  提交事务 T1 会对此事务记录Undo的日志文件,记录下事务开始之前的他俩账号余额: [开始事务 T1] [事务T1, A原有余额,200] [事务T1, B原有余额,50]  如果事务执行到一半挂了,数据库重启以后我就根据undo的日志文件来恢复。

Undo 日志

比如A有200块钱, B有50 块钱,现在A要给B转100块” 。

(1)  开始事务 T1 (假设T1是个事务的内部编号)

(2)  A余额 = A余额 -100

(3)  B余额 = B余额 + 100

(4)  提交事务 T1

会对此事务记录Undo的日志文件,记录下事务开始之前的他俩账号余额:

[开始事务 T1]

[事务T1, A原有余额,200]

[事务T1, B原有余额,50] 

如果事务执行到一半挂了,数据库重启以后我就根据undo的日志文件来恢复。

例子:如果第三步还没执行完就断电了, 数据库重启以后就需要根据undo日志复原,要是系统恢复的过程中又断电了,下次重启再次恢复,此操作拥有幂等性,重复多少次都没有问题。

如何判断哪些事务需要恢复

恢复之后需要在日志文件中加上一行 [回滚事务 T1] , 这样下一次恢复就不用再考虑T1这个事务了。

[开始事务 T1]

[事务T1, A原有余额,200]

[事务T1, B原有余额,50]

[提交事务 T1] 

Undo日志文件中不仅仅只有余额, 事务的开始和结束也会记录,如果我在日志文件中看到了[提交事务 T1], 或者 [回滚事务 T1], 就表示此事务已经结束,不用再去理会它了, 更不用去恢复。 如果我只看到 [开始事务 T1], 而找不到提交或回滚,那就得恢复。

日志从缓冲区写入磁盘的时机

 两条规则: 

1.  在最新余额写入硬盘之前, 一定要先把相关的Undo日志记录写入硬盘。 例如[事务T1, A原有余额,200] 一定要在A的新余额=100写入硬盘之前写入。 

2.  [提交事务 T1] 这样的Undo日志记录一定要在所有的新余额写入硬盘之后再写入。 

  操作 数据缓冲区

Undo日志缓冲区

1

 开始事务T1

 

 开始事务T1

2  A余额 = A余额 -100 A新余额:100  事务T1,A原有余额,200
3  把undo日志缓冲区内容写入磁盘   ps:此步骤会清空undo日志缓冲区
4  把A新余额写入磁盘    
5 B余额 = B余额 + 100 B新余额:150  
6  把undo日志缓冲区内容写入磁盘    
7  把B新余额写入磁盘    
8  提交事务T1   提交事务T1
9  把undo日志缓冲区内容写入磁盘    

情况一:

如果系统在第4步和第5步之间崩溃,A的余额写入了硬盘,但是B的还没写入, Undo日志看起来是这样的:

[开始事务 T1]

[事务T1, A原有余额,200] 

由于找不到事务结束的日志, 进行恢复操作, 把A的原有余额给恢复了。

情况二: 

如果是在第7步和第8步之间系统崩溃,A和B的最新余额都写入了硬盘,但是没有提交事务, 那Undo日志看起来是这样的:

[开始事务 T1]

[事务T1, 旺财原有余额,200]

[事务T1, 小强原有余额,50]

由于没有事务结束的日志,也需要进行恢复,把A和B的原有余额恢复成200和50 

情况三: 

如果是在第8步和第9步之间系统崩溃, A和B的最新余额都写入了硬盘也提交了事务, 但是提交事务的操作没有写入Undo 日志,Undo日志还是这样: 

[开始事务 T1]

[事务T1, 旺财原有余额,200]

[事务T1, 小强原有余额,50]

由于没有事务结束的日志,需要进行恢复,把A和B原有余额恢复成200和50

 

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
1月前
|
存储 监控 算法
防止员工泄密软件中文件访问日志管理的 Go 语言 B + 树算法
B+树凭借高效范围查询与稳定插入删除性能,为防止员工泄密软件提供高响应、可追溯的日志管理方案,显著提升海量文件操作日志的存储与检索效率。
84 2
|
9月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
769 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
8月前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
210 16
|
8月前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
162 4
|
9月前
|
运维 应用服务中间件 nginx
docker运维查看指定应用log文件位置和名称
通过本文的方法,您可以更高效地管理和查看Docker容器中的日志文件,确保应用运行状态可控和可监测。
1199 28
|
10月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
522 7
MySQL事务日志-Undo Log工作原理分析
|
8月前
|
SQL 存储 关系型数据库
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
1051 0
|
9月前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
316 0
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
362 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
11月前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
328 3

热门文章

最新文章

下一篇
oss云网关配置