redo log和undo log的区别

本文详细解释了数据库中的重做日志(redo log)与撤消日志(undo log)的作用与工作原理。重做日志记录数据更改以确保数据一致性,撤消日志则用于恢复数据至更改前状态。

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

redo log
重做日志
undo log
撤消日志

重做日志:每当有操作执行前,将数据真正更改时,先前相关操作写入重做日志。这样当断电,或者一些意外,导致后续任务无法完成时,系统恢复后,可以继续完成这些更改

撤消日志:当一些更改在执行一半时,发生意外,而无法完成,则可以根据撤消日志恢复到更改之前的壮态

网上找到一些解说:以便以后自己参考
有两个概念:前滚与回退
比如某一时刻数据库DOWN机了,有两个事务,一个事务已经提交,另一个事务正在处理
数据库重启的时候就要根据日志进行前滚及回退,把已提交事务的更改写到数据文件,未提交事务的更改恢复到事务开始前的状态。

redo--> undo-->datafile
insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据.

redo->每次操作都先记录到redo日志中,当出现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数据更新到数据文件
undo->记录更改前的一份copy,但你系统rollback时,把这份copy重新覆盖到原来的数据

redo->记录所有操作,用于恢复(redo records all the database transaction used for recovery)
undo->记录所有的前印象,用于回滚(undo is used to store uncommited data infor used for rollback)

redo->已递交的事务,实例恢复时要写到数据文件去的
undo->未递交的事务.

redo的原因是:每次commit时,将数据的修改立即写到online redo中,但是并不一定同时将该数据的修改写到数据文件中。因为该数据已经提交,但是只存在联机日志文件中,所以在恢复时需要将数据从联机日志文件中找出来,重新应用一下,使已经更改数据在数据文件中也改过来!

undo的原因是:在oracle正常运行时,为了提高效率,加入用户还没有commit,但是空闲内存不多时,会由DBWR进程将脏块写入到数据文件中,以便腾出宝贵的内存供其它进程使用。这就是需要UNDO的原因。因为还没有发出commit语句,但是oracle的dbwr进程已经将没有提交的数据写到数据文件中去了。

undo 也是也是datafile, 可能dirty buffer 没有写回到磁盘里面去。
只有先redo apply 成功了,才能保证undo datafile 里面的东西都是正确的,然后才能rollback

做undo的目的是使系统恢复到系统崩溃前(关机前)的状态,再进行redo是保证系统的一致性.
不做undo,系统就不会知道之前的状态,redo就无从谈起

所以instance crash recovery 的时候总是先rollforward, 再rollback

undo
回退段中的数据是以“回退条目”方式存储。
回退条目=块信息(在事务中发生改动的块的编号)+在事务提交前存储在块中的数据

在每一个回退段中oracle都为其维护一张“事务表”
在事务表中记录着与该回退段中所有回退条目相关的事务编号(事务SCN&回退条目)

redo
重做记录由一组“变更向量”组成。
每个变更变量中记录了事务对数据库中某个块所做的修改。
当用户提交一条commit语句时,LGWR进程会立刻将一条提交记录写入到重做日志文件中,然后再开始写入与该事务相关的重做信息。

#事务提交成功后,Oracle将为该事备生成一个系统变更码(SCN)。事务的SCN将同时记录在它的提交记录和重做记录中。

commit
提交事务前完成的工作:
·在SGA区的回退缓存中生成该事务的回退条目。在回退条目中保存有该事务所修改的数据的原始版本。
·在SGA区的重做日志缓存中生成该事务的重做记录。重做记录中记载了该事务对数据块所进行的修改,并且还记载了对回退段中的数据块所进行的修改。缓存中的重做记录有可能在事务提交之前就写入硬盘中。
·在SGA区的数据库缓丰中记录了事务对数据库所进行的修改。这些修改也有可能在事务提交之前就写入硬盘中。

提交事务时完成的工作:
·在为该事务指定的回退段中的内部事务表内记录下这个事务已经被提交,并且生成一个惟一的SCN记录在内部事务表中,用于惟一标识这个事务。
·LGWR后进进程将SGA区重做日志缓存中的重做记录写入联机重做日志文件。在写入重做日志的同时还将写入该事务的SCN。
·Oracle服务进程释放事务所使用的所有记录锁与表锁。
·Oracle通知用户事务提交完成。
·Oracle将该事务标记为已完成。

rollback
回退事务完成的工作:
·Oracle通过使用回退段中的回退条目,撤销事务中所有SQL语句对数据库所做的修改。
·Oracle服务进程释放事务所使用的所有锁
·Oracle通知事务回退成功。
·Oracle将该事务标记为已完成

举个例子:
insert into a(id) values(1);(redo)
这条记录是需要回滚的。
回滚的语句是delete from a where id = 1;(undo)

试想想看。如果没有做insert into a(id) values(1);(redo)
那么delete from a where id = 1;(undo)这句话就没有意义了。

现在看下正确的恢复:
先insert into a(id) values(1);(redo)
然后delete from a where id = 1;(undo)
系统就回到了原先的状态,没有这条记录了。

<think>好的,我现在需要详细回答用户关于MySQL中redo logundo log区别与作用的问题。用户已经提供了一些站内引用,我需要结合这些引用以及之前回答中的内容来构建一个全面且准确的解释。 首先,我需要明确redo logundo log的基本概念,然后分析它们的不同点,包括功能、存储位置、生命周期、日志类型、恢复方向以及关联事务等方面。同时,用户提到的引用中有关于两阶段提交日志结构的内容,这些也需要整合到回答中,确保覆盖关键点。 接下来,我应该检查之前的回答是否已经涉及了这些日志类型。在之前的回答中,用户主要关注错误日志、二进制日志、慢查询日志通用查询日志,而redo logundo log属于事务日志,需要在此次回答中详细展开。 需要确保回答结构清晰,分点说明,使用用户要求的格式,如行内数学表达式用$...$,独立公式用$$...$$,并且正确引用提供的参考资料。同时,生成相关问题,帮助用户进一步理解。 另外,要注意引用标记的正确使用,例如引用[^1]、[^2]等,这些需要与用户提供的引用对应起来。例如,用户提供的引用[1]提到redo logbinlog区别,引用[4]涉及两阶段提交恢复机制,这些都需要在适当的位置引用。 最后,总结redo logundo log区别与作用,确保内容准确,语言简洁,符合用户要求的中文回答,并生成相关问题供用户参考。</think>### MySQL中redo logundo log的对比解析 --- #### 一、核心概念与作用对比 1. **redo log(重做日志)** - **功能定位**:InnoDB存储引擎层日志,确保事务的**持久性**(Durability) - **核心作用**: - 记录物理层面的数据页修改(例如:$page\_no=5$的页中偏移量$offset=128$处更新为值$0x1A3F$)[^1][^4] - 用于崩溃恢复时**重放未写入数据文件的修改** - **写入机制**: - 采用**循环写入**模式(固定大小文件组) - 通过`innodb_flush_log_at_trx_commit`参数控制刷盘策略[^4] 2. **undo log(回滚日志)** - **功能定位**:实现事务的**原子性**(Atomicity)与多版本并发控制(MVCC) - **核心作用**: - 记录事务修改前的数据镜像,支持事务回滚(`ROLLBACK`) - 为读操作提供一致性视图(通过`Read View`访问历史版本数据)[^2] - **存储形式**: - 以**逻辑日志**形式记录反向操作(例如:INSERT对应DELETE,UPDATE记录旧值) - 存储在特殊的undo表空间中(MySQL 8.0默认使用独立UNDO表空间) --- #### 二、关键差异分析 | **对比维度** | **redo log** | **undo log** | |--------------------|---------------------------------------|---------------------------------------| | **所属层级** | InnoDB存储引擎层实现[^4] | InnoDB存储引擎层实现[^4] | | **日志类型** | 物理日志(记录数据页修改) | 逻辑日志(记录反向操作语句) | | **主要目的** | 崩溃恢复时保证数据持久性 | 事务回滚与MVCC支持 | | **生命周期** | 事务提交后仍可能保留(用于恢复) | 事务提交后随版本链清理逐渐删除 | | **写入触发条件** | 数据修改发生时立即记录 | 事务开启后首次数据修改时生成 | | **可见性** | 仅InnoDB内部使用 | 通过`SELECT ... FOR UPDATE`可间接访问| | **与事务的关系** | 所有事务共享日志缓冲区 | 每个事务拥有独立的undo链 | --- #### 三、协作流程示例(以UPDATE为例) 1. **事务启动**:生成事务ID(trx_id)并分配undo log段 2. **修改数据前**: - 将原始数据拷贝到undo log(构建回滚段) - 生成`UNDO LOG RECORD`记录旧值[^4] 3. **执行数据修改**: - 在内存中更新数据页,生成`redo log record`写入log buffer - 若开启binlog,同时写入binlog cache(两阶段提交)[^4] 4. **事务提交**: - 将redo log buffer刷盘(`prepare`阶段) - binlog刷盘后,redo log标记为`commit`状态[^4] 5. **崩溃恢复**: - 检查binlog完整性,通过redo log重做未落盘的数据页修改 - 使用undo log回滚未提交的事务修改 --- #### 四、高级特性关联 1. **两阶段提交(2PC)** redo log与binlog通过两阶段提交保证跨存储引擎的事务一致性[^4]: ```mermaid graph LR A(事务提交) --> B(redo log prepare) B --> C(binlog写入) C --> D(redo log commit) ``` 2. **MVCC实现基础** 通过undo log构建版本链实现非锁定读: $$ \text{Read View} = [trx\_id_{min}, trx\_id_{max}, active\_trx\_list] $$ 根据事务ID选择可见的undo log版本 --- #### 五、配置与管理要点 1. **redo log优化** - 设置合理的日志文件大小(`innodb_log_file_size`,建议4GB以上) - 调整刷盘策略(`innodb_flush_log_at_trx_commit=1`确保ACID) ```ini [mysqld] innodb_log_files_in_group=3 # 日志文件数量 innodb_log_file_size=4G # 单个文件大小 ``` 2. **undo log管理** - 控制undo表空间数量(MySQL 8.0+) - 设置自动清理阈值(`innodb_undo_log_truncate=ON`) ```sql ALTER UNDO TABLESPACE innodb_undo_001 SET INACTIVE; # 手动触发清理 ``` --- ### 相关问题 1. 如何通过redo log实现崩溃恢复的具体流程? 2. undo log在MVCC中如何支持一致性读? 3. 两阶段提交如何避免binlogredo log数据不一致? 4. 什么情况下需要调整redo log文件的大小?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值