崩溃恢复（Crash Recovery）的原理：Redo Log 与 Undo Log 的作用

admin
Thu, 05 Jun 2025 06:35:59 +0000
Mysql, crash, log, recovery

好的，各位编程界的英雄好汉、靓女萌妹们，今天咱们来聊聊一个听起来有点吓人，但实际上很有意思的话题：崩溃恢复！想象一下，你辛辛苦苦写了一天的代码，正准备提交，结果电脑突然蓝屏了……那种感觉，简直比失恋还难受啊！ 别怕，有了崩溃恢复，你的数据就有了救星！它就像一个超级英雄，能在系统崩溃后，把数据从悬崖边拉回来。而 Redo Log 和 Undo Log，就是这位超级英雄的两大法宝。今天咱们就来好好扒一扒这两大法宝的原理和作用。 开场白：数据世界的“生死时速” 在数据库的世界里，数据就像血液一样流动，而对数据的修改就像一场场紧张刺激的“生死时速”。每一次事务（Transaction）的执行，都可能改变数据库的状态。但天有不测风云，数据库系统随时可能遭遇各种“意外事故”，比如： 服务器突然断电： 就像赛车突然没油，直接熄火。 操作系统崩溃： 就像赛车撞到护栏，车毁人亡。 数据库软件 Bug： 就像赛车零件脱落，跑着跑着就散架了。 这些“意外事故”会导致数据处于一种“半死不活”的状态，要么事务只执行了一半，要么数据被改得乱七八糟。如果没有一套完善的崩溃恢复机制，数据就会彻底丢失或损坏，那损失可 …

继续阅读“崩溃恢复（Crash Recovery）的原理：Redo Log 与 Undo Log 的作用”

The post 崩溃恢复（Crash Recovery）的原理：Redo Log 与 Undo Log 的作用 first appeared on 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座.

好的，各位编程界的英雄好汉、靓女萌妹们，今天咱们来聊聊一个听起来有点吓人，但实际上很有意思的话题：崩溃恢复！想象一下，你辛辛苦苦写了一天的代码，正准备提交，结果电脑突然蓝屏了……那种感觉，简直比失恋还难受啊！

别怕，有了崩溃恢复，你的数据就有了救星！它就像一个超级英雄，能在系统崩溃后，把数据从悬崖边拉回来。而 Redo Log 和 Undo Log，就是这位超级英雄的两大法宝。今天咱们就来好好扒一扒这两大法宝的原理和作用。

开场白：数据世界的“生死时速”

在数据库的世界里，数据就像血液一样流动，而对数据的修改就像一场场紧张刺激的“生死时速”。每一次事务（Transaction）的执行，都可能改变数据库的状态。但天有不测风云，数据库系统随时可能遭遇各种“意外事故”，比如：

服务器突然断电： 就像赛车突然没油，直接熄火。

操作系统崩溃： 就像赛车撞到护栏，车毁人亡。

数据库软件 Bug： 就像赛车零件脱落，跑着跑着就散架了。

这些“意外事故”会导致数据处于一种“半死不活”的状态，要么事务只执行了一半，要么数据被改得乱七八糟。如果没有一套完善的崩溃恢复机制，数据就会彻底丢失或损坏，那损失可就大了去了！

第一幕：Redo Log——“起死回生”的仙丹妙药

Redo Log，顾名思义，就是“重做日志”。它记录的是事务对数据所做的修改操作。你可以把它想象成一个“录像机”，忠实地记录下每一个数据变化的瞬间。

Redo Log 的工作原理：

1. 事务开始： 就像赛车手准备出发，Redo Log 开始“录像”。

2. 修改数据： 每次事务修改数据时，都会先将修改操作写入 Redo Log。 比如，把账户 A 的余额从 100 元改成 200 元，Redo Log 就会记录下：“将账户 A 的余额修改为 200 元”。

3. 提交事务： 只有当 Redo Log 记录完成后，事务才会正式提交。 这就像赛车手冲过终点线，比赛才算结束。

4. 写入磁盘： Redo Log 会定期将记录写入磁盘，保证即使系统崩溃，数据也不会丢失。

Redo Log 的作用：

恢复已提交的事务： 如果系统在事务提交后崩溃，Redo Log 可以重放这些已提交的事务，确保数据最终一致。 这就像赛车手虽然撞车了，但通过录像回放，仍然可以知道他已经完成了比赛。

举个例子：

假设一个事务 T1 要将账户 A 的余额从 100 元改成 200 元，然后将账户 B 的余额从 300 元改成 400 元。

1. T1 开始执行。

2. Redo Log 记录：UPDATE A SET balance = 200 WHERE id = A_ID

3. Redo Log 记录：UPDATE B SET balance = 400 WHERE id = B_ID

4. T1 提交。

如果在 T1 提交后，系统突然崩溃，那么在恢复时，数据库会读取 Redo Log，发现 T1 已经提交，就会重放 Redo Log 中的操作，将账户 A 和 B 的余额都恢复到最新值。

Redo Log 的优点：

速度快： Redo Log 只需要记录修改操作，不需要记录完整的数据副本，因此写入速度很快。

简单： Redo Log 的实现相对简单，易于维护。

Redo Log 的缺点：

无法撤销未提交的事务： Redo Log 只能重做已提交的事务，无法撤销未提交的事务。 如果系统在事务提交前崩溃，Redo Log 就无能为力了。

第二幕：Undo Log——“时光倒流”的后悔药

Undo Log，顾名思义，就是“撤销日志”。它记录的是事务对数据所做的原始值。你可以把它想象成一个“备份机”，记录下数据修改前的状态。

Undo Log 的工作原理：

1. 事务开始： 就像魔术师准备表演，Undo Log 开始“备份”。

2. 修改数据： 每次事务修改数据时，都会先将修改前的原始值写入 Undo Log。 比如，把账户 A 的余额从 100 元改成 200 元，Undo Log 就会记录下：“账户 A 的原始余额是 100 元”。

3. 提交事务： 只有当 Undo Log 记录完成后，事务才能真正开始修改数据。 这就像魔术师先准备好道具，才能开始表演。

4. 回滚事务： 如果事务需要回滚（比如遇到错误），Undo Log 可以恢复数据的原始值。 这就像魔术师表演失败，需要把道具恢复原状。

Undo Log 的作用：

撤销未提交的事务： 如果系统在事务提交前崩溃，Undo Log 可以撤销这些未提交的事务，保证数据的一致性。 这就像赛车手虽然撞车了，但通过“时光倒流”，可以回到比赛开始前的状态。

实现事务回滚： 当事务执行过程中发生错误时，可以使用 Undo Log 将数据恢复到事务开始前的状态。

举个例子：

假设一个事务 T2 要将账户 C 的余额从 500 元改成 600 元，然后将账户 D 的余额从 700 元改成 800 元。

1. T2 开始执行。

2. Undo Log 记录：UPDATE C SET balance = 500 WHERE id = C_ID (记录 C 的原始值)

3. 执行 UPDATE C SET balance = 600 WHERE id = C_ID

4. Undo Log 记录：UPDATE D SET balance = 700 WHERE id = D_ID (记录 D 的原始值)

5. 执行 UPDATE D SET balance = 800 WHERE id = D_ID

6. T2 提交。

如果在 T2 提交前，系统突然崩溃，那么在恢复时，数据库会读取 Undo Log，发现 T2 尚未提交，就会利用 Undo Log 中的信息，将账户 C 和 D 的余额恢复到原始值（500 元和 700 元）。

Undo Log 的优点：

可以撤销未提交的事务： 这是 Undo Log 最重要的优点，可以保证数据的一致性。

支持事务回滚： Undo Log 可以让事务“后悔”，回到之前的状态。

Undo Log 的缺点：

速度慢： Undo Log 需要记录数据的原始值，写入量较大，因此速度较慢。

实现复杂： Undo Log 的实现相对复杂，需要考虑各种情况。

第三幕：Redo Log + Undo Log = 完美搭档

Redo Log 和 Undo Log 就像一对“黄金搭档”，互相配合，共同完成崩溃恢复的任务。

崩溃恢复的步骤：

1. 分析阶段： 扫描 Redo Log 和 Undo Log，确定哪些事务已经提交，哪些事务尚未提交。

2. Redo 阶段： 重做所有已提交的事务。

3. Undo 阶段： 撤销所有未提交的事务。

举个例子：

假设系统在执行以下操作时崩溃：

1. 事务 T1：将账户 A 的余额从 100 元改成 200 元 (已提交)

2. 事务 T2：将账户 B 的余额从 300 元改成 400 元 (未提交)

在崩溃恢复时：

1. 分析阶段： 发现 T1 已经提交，T2 尚未提交。

2. Redo 阶段： 重做 T1，将账户 A 的余额改为 200 元。

3. Undo 阶段： 撤销 T2，将账户 B 的余额恢复到 300 元。

表格总结：Redo Log vs. Undo Log

特性 | Redo Log | Undo Log
记录内容 | 修改操作 | 原始值
主要作用 | 重做已提交事务 | 撤销未提交事务
写入速度 | 快 | 慢
实现复杂度 | 简单 | 复杂
适用场景 | 提交后崩溃 | 提交前崩溃

第四幕：Aries 算法——崩溃恢复的“葵花宝典”

Aries (Algorithm for Recovery and Isolation Exploiting Semantics) 是一种经典的崩溃恢复算法，被广泛应用于各种数据库系统中。它就像崩溃恢复界的“葵花宝典”，威力强大，但修炼起来也需要一定的功力。

Aries 算法的核心思想是：

Write-Ahead Logging (WAL)： 所有的数据修改都必须先写入 Redo Log，才能真正修改数据库。 这就像盖房子必须先打地基，确保万无一失。

Repeat History： 崩溃恢复时，尽可能地重现历史操作，确保数据的一致性。

Aries 算法的具体步骤比较复杂，涉及到 LSN (Log Sequence Number，日志序列号) 等概念，这里就不深入展开了。 简单来说，Aries 算法就是通过 Redo Log 和 Undo Log 的精妙配合，实现了高效可靠的崩溃恢复。

总结：数据安全的“双保险”

Redo Log 和 Undo Log 是数据库崩溃恢复的两大法宝，它们就像数据安全的“双保险”，共同守护着数据的安全。Redo Log 负责“起死回生”，恢复已提交的事务；Undo Log 负责“时光倒流”，撤销未提交的事务。两者配合，可以保证即使系统崩溃，数据也能恢复到一致的状态。

掌握了 Redo Log 和 Undo Log 的原理，你就能更好地理解数据库的底层机制，也能更好地应对各种数据安全问题。希望这篇文章能帮助你更深入地了解崩溃恢复的奥秘！

结尾：编程世界的“守护神”

崩溃恢复技术就像编程世界的“守护神”，默默地守护着我们的数据安全。 虽然我们平时可能很少接触到它，但它却在背后默默地工作，确保我们的数据万无一失。 让我们向这些默默奉献的“守护神”致敬！

希望这篇文章能让你对崩溃恢复有更深入的了解。 记住，数据安全无小事，让我们一起努力，构建更安全可靠的系统！