redo log的管理

1.添加日志组
alter database add logfile group 1 ('/u02/oradata/bolan/redo01.log') size 100m;
2.添加日志组成员
alter database add logfile member '/u02/oradata/bolan/redo01.log' to group 1;
3.删除日志组
alter database drop logfile group 1;
4.删除日志组成员
alter database drop logfile member '/u02/oradata/bolan/redo01.log';

1.添加镜像日志
alter database add standby logfile group 1 ('/u02/oradata/bolan/redo01.log') size 100m;
2.添加镜像日志组成员
alter database add standby logfile member '/u02/oradata/bolan/redo01.log' to group 1;
3.删除镜像日志
alter database drop standby logfile group 1;
4.添加镜像日志组成员
alter database drop standby logfile member '/u02/oradata/bolan/redo01.log';

<think>我们正在讨论MySQL的undo logredo log。用户要求详细介绍这两种日志。根据引用内容,我们可以总结如下: 引用[1]和[2]指出: - Redo Log(重做日志)和Undo Log(撤销日志)用于确保数据完整性和事务一致性。 - 它们在事务回滚和系统恢复中起关键作用。 引用[2]进一步说明: - Undo Log用于保障事务的原子性(回滚)和一致性。 - Redo Log用于保障事务的持久性。 引用[3]和[4]补充: - Undo Log记录事务修改前的数据,用于回滚。 - Redo Log记录事务修改后的数据,用于崩溃恢复。 引用[5]强调: - 当事务修改数据时,Undo Log会先保存原始数据,以便回滚时恢复。 - Redo Log则记录修改后的新数据,确保已提交事务的持久性。 我们需要详细说明这两种日志,包括它们的作用、工作原理、存储方式以及协同工作的情况。 回答结构: 1. 概述Undo LogRedo Log的作用和区别 2. 分别详细介绍Undo Log - 原理 - 实现机制 - 作用 3. 分别详细介绍Redo Log - 原理 - 实现机制 - 作用 4. 两者协同工作流程(例如在事务提交和崩溃恢复时) 5. 总结 注意:在回答中适当添加引用标识。 另外,根据指令,需要生成相关问题。 </think>### Undo LogRedo Log 深度解析 MySQL 通过 **Undo Log(撤销日志)** 和 **Redo Log(重做日志)** 协同保障事务的 ACID 特性,以下是详细分析: --- #### 一、Undo Log:事务回滚与多版本控制的核心 **本质作用**:记录数据修改前的原始状态,实现**原子性(Atomicity)** 和**多版本并发控制(MVCC)**[^2][^5]。 **核心机制**: 1. **数据回滚** - 事务修改数据前,将原始值写入 Undo Log - 回滚时执行逆向操作: $$Rollback = Apply(UndoLog\_Record)$$ - 示例:UPDATE 语句失败时,通过 Undo Log 复原数据[^5] 2. **MVCC 支持** - 存储数据的历史版本(通过 `DB_ROLL_PTR` 指针链式存储) - 读操作访问对应版本快照,避免读写冲突 ```mermaid graph LR A[事务TX1读数据] --> B[检查Undo Log版本链] B --> C{选择TX1启动前的版本} C -->|是| D[返回历史快照] C -->|否| E[跳过新版本] ``` 3. **存储特性** - 位于共享表空间的 `ibdata1` 文件中 - 采用**段管理**(UNDO Segments) - 空间回收由 Purge 线程异步处理[^3] --- #### 二、Redo Log:崩溃恢复与持久化的基石 **本质作用**:确保**持久性(Durability)**,防止事务提交后数据丢失[^1][^4]。 **核心机制**: 1. **Write-Ahead Logging (WAL)** - 修改数据前先写 Redo Log:$Commit \rightarrow Write(RedoLog) \rightarrow Flush(DataPage)$ - 日志写入顺序:内存 Log Buffer → 磁盘 Log File[^3] 2. **崩溃恢复流程** ```python def crash_recovery(): scan_redo_log() # 扫描所有Redo记录 for log in committed_tx: # 重做已提交事务 apply_log_to_page(log) for log in active_tx: # 撤销未提交事务(需结合Undo Log) rollback_via_undo(log) ``` 3. **日志结构优化** - **循环写入**:固定大小文件(通常 4GB),写满后覆盖旧日志 - **LSN 机制**:Log Sequence Number 全局唯一标识日志位置 - **组提交**:合并多个事务 I/O,提升吞吐量[^4] --- #### 三、Undo LogRedo Log 的协同 | **场景** | **协作流程** | 关键目标 | |-------------------|-----------------------------------------------------------------------------|-----------------------| | **事务提交** | 1. Redo Log 持久化<br>2. Binlog 写入(若开启)<br>3. 内存数据页异步刷盘 | 持久性保障[^3] | | **事务回滚** | 1. 从 Undo Log 读取旧值<br>2. 通过 Redo Log 记录回滚操作 | 原子性实现[^2] | | **崩溃恢复** | 1. Redo Log 重做已提交操作<br>2. Undo Log 回滚未提交事务 | 一致性恢复[^1] | | **MVCC 读** | 1. 通过 Undo Log 定位历史版本<br>2. Redo Log 确保版本数据有效性 | 隔离性支持[^5] | **协同公式**: $$Atomicity_{Undo} + Durability_{Redo} \Rightarrow Consistency$$ --- #### 四、关键差异总结 | **特性** | Undo Log | Redo Log | |-----------------|-----------------------------------|-----------------------------------| | **核心目的** | 回滚事务 + MVCC 版本链 | 崩溃恢复 + 数据持久化 | | **写入时机** | 事务修改数据**前** | 事务提交**前** | | **存储内容** | 数据修改**前**的原始值 | 数据修改**后**的新状态 | | **日志类型** | 逻辑日志(记录逆向 SQL) | 物理日志(记录页修改) | | **空间回收** | 事务提交后异步 Purge | 检查点推进后覆盖旧日志 | | **性能影响** | 影响回滚速度 + 读性能 | 决定提交延迟 + 恢复速度 | > **设计哲学**:Undo Log 是"后悔药",Redo Log 是"安全气囊",二者共同构建事务安全网[^1][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值