一分钟理解Redo Undo

本文解析了数据库中Redo与Undo日志的工作原理,它们在数据修改时不直接写入数据文件,而是先记录在日志中,待条件成熟再刷新数据,确保在系统崩溃时能通过日志恢复数据一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

数据库中有一种特殊的“日志文件”叫 Redo(重做) Undo(撤销),传统意义上的日志文件是记录系统运行状态的,主要用于系统工程师或者程序员排错。而 Reod/Undo 文件是数据库的一部分,主要用于数据恢复,保证数据的一致性和完整性。

用途

当执行 Insert、Update、Delete 动作时数据库不会真的去数据文件中执行 I/O 操作,而是分了两部分:

  • 修改内存中的数据(数据库称为 Buffer)

  • 记录 Redo Undo 日志

只有当 Buffer 达到刷新条件(比如脏数据达到一定比例)才会对数据文件进行操作。数据库这么设计是出于性能考虑,因为读写数据文件是一次随机 I/O 会降低系统性能;虽然 Redo Undo 也会写文件,但它是顺序写入,性能比较高。

这种顺序写入一般采用 LSM (Log Structured Merge Trees)算法,比如 Kafka,HBase、LevelDB 都采用这种结构。

因为数据并没有真正的写入数据文件,所以当数据库系统崩溃后(比如断电、系统重启、介质错误),数据库系统会利用Redo、Undo 恢复数据。

如何恢复

两个原则

  • 从前向后读取 Redo,重做所有已提交的事务

  • 从后往前读取 Undo,回滚未提交的事务

以上面操作为例,假设故障点发生在第一个 Write 之后。数据库启动后读取 Redo 文件没有发现已经提交的事务,什么也不做;读取 Undo 文件发现未提交的事务,恢复 X=0(假设 X 历史值为 0)。

假设故障点发生在第二个 Write 之后数据库启动后读取 Redo 文件发现没有已经提交的事务,什么也不做;读取 Undo 文件发现未提交的事务,恢复 X=1,继续回滚X=0。

假设故障点发生在 Commit 之后数据库启动后读取 Redo 文件发生已经提交的事务,执行 X=1,然后 X=2;读取 Undo 文件发现提交事务,什么也不做。

多个事务也是如此,读者可以自行尝试枚举

posted on 2018-12-17 13:57 fhwup 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/fhwup/p/10131122.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值