mysql 崩溃恢复

最新推荐文章于 2025-08-17 18:29:45 发布
原创 最新推荐文章于 2025-08-17 18:29:45 发布 · 171 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql

本文详细介绍了MySQL在崩溃后的恢复流程及判断规则。对于redolog中已提交的事务将直接提交；对于仅有prepare标记的事务，会进一步检查binlog的完整性来决定提交还是回滚。

1.mysql崩溃恢复时的判断规则：

a.如果redo log里的事务是完整的，即已经有了commit标识，则直接提交；

b.如果redo log里的事务只有完整的prepare，则判断对应的binlog是否存在并完整：

           b.1:如果是，则提交事务；b.2:否则，回滚事务

MySQL数据库InnoDB崩溃恢复机制
BjmmVue的博客
10-02 587
MySQL数据库InnoDB引擎提供了可靠的崩溃恢复机制，通过事务日志记录和重做操作，可以确保数据库在崩溃后的一致性和完整性。恢复检查点是数据库在某个时间点上的一致性状态的快照，它记录了数据库中的所有已提交的事务所进行的修改。(a) 回滚未完成的事务：首先，InnoDB会检查事务日志，找到最近一次提交的事务，并回滚未完成的事务，将数据库恢复到最后一次提交的状态。(a) 回滚未完成的事务：首先，InnoDB会检查事务日志，找到最近一次提交的事务，并回滚未完成的事务，将数据库恢复到最后一次提交的状态。
MySQL 崩溃恢复过程分析
weixin_57907028的博客
09-14 2408
MySQL 崩溃也是一次关闭过程，只是比正常关闭着急了一些。正常关闭时，MySQL 会做一系列收尾工作，例如：清理 undo 日志、合并 change buffer 缓冲区等操作。具体会进行哪些收尾工作，取决于系统变量 innodb_fast_shutdown 的配置。崩溃直接就是戛然而止，撂挑子不干了，还没来得及进行的那些收尾工作怎么办？那就只能等待下次启动的时候再干了，这就是本文要介绍的崩溃恢复过程。
MySQL高级讲座篇之：MySQL崩溃恢复：`Redo Log`与`Undo Log`的恢复之旅。
最新发布
weixin_41455464的博客
08-17 719
希望通过今天的讲解，大家对MySQL的崩溃恢复机制有了更深入的了解。问题来了：如果数据库在第2步完成，但第3步还没来得及做的时候崩溃了，那数据就丢失了，因为内存中的修改还没持久化到磁盘上。它记录的是逻辑级别的修改，也就是“把哪个页面的哪个记录改成什么”。它记录的是物理级别的修改，也就是“把哪个页面的哪个字节改成什么”。的工作原理，可以帮助我们更好地理解MySQL的事务机制，从而写出更高效、更可靠的SQL语句。中记录的信息，将数据恢复到原始状态，保证事务的原子性。
mysql 将秒改成00_一起看下MySQL的崩溃恢复到底是怎么回事
weixin_40004659的博客
12-23 275
思考一个问题为什么在你当update时，事物提交之前先不断的写redo log呢？如果你看过白日梦前面介绍buffer pool的文章，这个问题的答案想必你也能很快的想出来：MySQL为了提高性能，你对它数据行的增、删、改操作其实都优先发生在内存(Buffer Pool)中。那你想，假如你update了某些数据，Buffer Pool中的数据页也就会被你改成脏数据页。那万一你刚修改完并提交了事物，...
MySQL崩溃恢复
三思的博客
06-26 1844
一、一些小概念 1.1 MySQL的关闭相关参数 MySQL正常关闭时需要做哪些操作一般通过参数innodb_fast_shutdown进行控制，若MySQL异常关闭crash，那么就相当于innodb_fast_shutdown=2的情况，下面是该参数的详细介绍： innodb_fast_shutdown 0：在该模式下关闭MySQL时所做的操作是最多的，也是最耗时的，但是该模式下MySQL的启动是最快的，主要做三个动作： 1）flush dirty pages（脏页落盘） 2）merge chang
mysql崩溃恢复算法_浅析MySQL 8.0崩溃恢复
weixin_34379088的博客
01-19 730
本文将结合MySQL 8.0.19 分析InnoDB崩溃恢复的拉起过程，包括恢复前的准备工作，redo回放，undo回滚，以及崩溃恢复后Crash Safe DDL的实现。其中重点介绍redo的回放。整体的代码流程如下，InnoDB崩溃恢复的流程是从srv_start， innobase_dict_recover ，ha_post_recover这三个函数中展开，后文会详细介绍。|-->my...
基于Redo log & Undo log的MySQL的崩溃恢复
憨憨小江的博客
02-28 1002
redo log + binlog 的崩溃恢复
海山数据库(He3DB)源码详解：海山Mysql 崩溃恢复（1）-准备及结束
于巍，花名漠雪，移动云数据库技术委员会主任，海山数据库研发负责人，PG中文社区常委，PG中文社区海外联络人。15年数据库内核研发经验，4年美国、以色列等海外研发经历，华为GaussDB、阿里云PolarDB、移动云He3DB等核心架构
12-17 1074
选取最近发生的那次checkpoint的信息。衡量checkpoint发生时间早晚的信息就是所谓的，只要把和这两个block中的值读出来比一下大小，哪个的值更大，说明哪个block存储的就是最近的一次checkpoint信息。这样就能拿到最近发生的checkpoint对应的值以及它在redo日志文件组中的偏移量。为什么要把checkpoint信息存储到2个block中？万一就在某次写checkpoint信息的过程中MySQL崩溃了，有可能导致正在写入的这个block中的checkpoint信息不正确。
MySQL---redo log（崩溃恢复）
Elmer的博客
11-18 5286
redo log（重做日志）是 InnoDB 存储引擎独有的，它让 MySQL 拥有了。比如 MySQL 实例挂了或宕机了，重启时，InnoDB 存储引擎会使用 redo log 恢复数据，MySQL 中数据是以为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫，会放入到中。后续的查询都是先从中找，没有命中再去硬盘加载，减少硬盘 IO 开销，提升性能。更新表数据的时候，也是如此，发现里存在要更新的数据，就直接在里更新。然后会把“”记录到）里，接着刷盘到 redo log 文件里。
mysql崩溃恢复
diaozhou2796的博客
03-09 202
mysql崩溃恢复 mysql进程崩溃。 杀掉所有mysql进程，在my.cnf文件中写入innodb_recover_force=1，强制并忽略任何错误启动数据库。 用mysqldump导出所有数据，在新机器上部署好mysql，导入。 ...
MySQL InnoDB 日志 回滚段 & 崩溃恢复实现详解 修改版
03-02
MySQL InnoDB 日志 回滚段 & 崩溃恢复实现详解 修改版
MySQL数据库INNODB 表损坏修复处理过程
11-13
MySQL报警，从库的数据库挂了，一直在不停的重启，打开错误日志，发现有张表坏了。innodb表损坏不能通过repair table 等修复myisam的命令操作。
MySQL数据库崩溃与恢复-日常问题
分享技术相关博文
05-16 929
将mysql进行备份和恢复时（可以去看我的之前文章数据库的备份和迁移方法），启动运行后发生问题，可能由于相关表异常导致服务挂了，下面是进行排查和解决。
mysql崩溃恢复过程_一起看下MySQL的崩溃恢复到底是怎么回事
weixin_39533432的博客
01-19 453
思考一个问题为什么在你当update时，事物提交之前先不断的写redo log呢？如果你看过白日梦前面介绍buffer pool的文章，这个问题的答案想必你也能很快的想出来：MySQL为了提高性能，你对它数据行的增、删、改操作其实都优先发生在内存(Buffer Pool)中。那你想，假如你update了某些数据，Buffer Pool中的数据页也就会被你改成脏数据页。那万一你刚修改完并提交了事物，...
MySQL数据库崩溃恢复
悟能的师兄的专栏
10-11 3509
前置条件：重要的事情说三遍，免得误操作！ 不是你删了数据，是系统断电或者硬盘坏点导致的启动失败！！！ 不是你删了数据，是系统断电或者硬盘坏点导致的启动失败！！！ 不是你删了数据，是系统断电或者硬盘坏点导致的启动失败！！！ MySQL坏点恢复不了，ibdata1 文件损坏，数据库已经无法启动，并且你的数据库备份无法使用！ 一：MySQL数据库恢复 因为我们既无法从备份恢复，也无法从ibdata1 启动恢复，这个时候我们需要将我们的数据库表以及数据库表数据恢复。 首先我们需要安装一个新的数据库哈，
mysql崩溃数据恢复
cleanfield的专栏
03-05 2863
<br />1.保存好data目录<br />2.重新安装mysql<br />3.如果表引擎是myisam的话，直接将对应数据库目录下的文件拷贝回来，重启mysql就可以看到数据还在<br />4.如果表引擎是innodb的话，将数据库目录下的frm文件拷贝回来，然后将ibdata1文件拷到data目录下，在my.ini文件中添加innodb_force_recovery=1这个设置，重启mysql就会看到数据已经回来
mysql数据库崩溃，修复
weixin_34185364的博客
05-18 739
整理了7条修复MySQL数据库的方法，当简单的重启对数据库不起作用，或者有表崩溃时。 简单的MySQL重启： /usr/local/mysql/bin/mysqladmin -uUSERNAME -pPASSWORD shutdown /usr/local/mysql/bin/mysqld_safe & 1、MyISAM表崩溃 MySQL数据库允许不同的表使...
MySQL数据库崩溃
七天
02-25 922
MySQL数据库崩溃
MySQL崩溃后的恢复
不完美的红烧肉的博客
11-04 1280
这种情况下，意味着事务失败，我们希望系统可以恢复到事务开始前的状态。但是有可能部分redo log已经落盘了，此时如果通过redo log恢复系统，则会造成出现脏数据的现象。系统会从undo log中找到当前为active的事务ID，即未提交的事务id，把这些事务对应的改动全部回滚掉，从而保证了事务的原子性。我们知道，一般情况下，事务提交时，redo log buffer会强制刷盘。所以系统崩溃后，系统可以通过redo log恢复系统到崩溃前的状态，从而保证了事务持久性。
在MySQL崩溃恢复中，redo log和undo log的具体执行顺序是怎样的？
07-22
<think>嗯，用户现在想了解MySQL崩溃恢复中redo log和undo log的执行顺序。之前已经详细讨论过redo log和binlog的区别，用户可能是在深入学习事务机制时遇到了这个问题。 从引用内容看，用户提供的参考资料很专业，特别是引用[1]和[2]详细解释了两种日志的机制。用户似乎已经理解了基本概念，现在更关注它们在崩溃恢复时的交互顺序。 注意到引用[2]特别强调“Redo Log记录物理修改”和“BinLog记录逻辑修改”的区别，这很重要。在崩溃恢复场景下，物理日志必须先处理，因为需要先修复数据页的物理状态，才能进行后续逻辑操作。 用户引用的资料中还提到undo log的删除机制（引用[4]）和LSN记录（引用[3]），这些都会影响恢复流程。需要把这些点融入解释中。 考虑到用户之前的问题都比较深入，这次回答应该： 第一，明确分步骤说明恢复流程 第二，用LSN作为关键线索串联整个过程 第三，强调undo log在回滚阶段的决定性作用 第四，补充一个典型崩溃场景的示例 需要特别注意技术细节的准确性： - redo log的prepare状态如何影响恢复判断 - 为什么undo log的应用必须在redo log之后 - 检查点(checkpoint)在恢复时的关键作用 最后生成的思考题要延续事务日志的主题，比如两阶段提交的崩溃处理、undo log存储优化等，帮助用户建立系统认知。</think>在MySQL崩溃恢复过程中，**redo log和undo log的执行顺序严格遵循“先重做(redo)后回滚(undo)”的原则**，具体流程如下： --- ### **崩溃恢复核心流程** #### **1. 重做阶段 (Redo Phase)** ```mermaid graph LR A[崩溃重启] --> B[扫描redo log] B --> C{检查LSN<br>（Log Sequence Number）} C -->|定位| D[最近检查点] D --> E[重做所有已提交/未提交事务的修改] E --> F[将数据页恢复到崩溃前状态] ``` - **执行顺序**： 1️⃣ 从最近检查点（Checkpoint）开始扫描redo log 2️⃣ 按LSN顺序**重放所有物理修改**（包括已提交和未提交事务）[^3] 3️⃣ 将数据页恢复到崩溃瞬间的物理状态 - **关键点**： - 此阶段**仅依赖redo log**，无视事务状态 - 通过`Write-Ahead Logging`机制确保数据页完整性[^1][^2] #### **2. 回滚阶段 (Undo Phase)** ```mermaid graph LR G[扫描undo log] --> H{事务状态判断} H -->|未提交事务| I[应用undo log回滚] H -->|已提交事务| J[跳过] I --> K[生成回滚SQL<br>撤销修改] ``` - **执行顺序**： 1️⃣ 扫描undo log链，识别所有**未提交事务**（通过事务状态标记） 2️⃣ 按事务逆向应用undo log，执行回滚操作 3️⃣ 释放未提交事务占用的锁和资源[^4] - **关键点**： - 仅处理**未提交事务**，已提交事务跳过 - undo log通过**指针链式结构**保证回滚顺序[^1][^4] --- ### **执行顺序的深层逻辑** 1. **物理优先于逻辑** - redo log记录**物理页修改**（如“页#5偏移0x10写入值0xFF”），需优先恢复数据页基础结构[^2] - undo log记录**逻辑操作**（如“原始值0x00”），依赖完整的数据页才能执行回滚 2. **事务状态依赖** - 崩溃瞬间事务状态丢失，需先通过redo log恢复数据页，才能从页中读取事务ID和状态标记 - 例如：数据页的事务ID是判断是否回滚的关键依据 3. **LSN的协同作用** | 日志类型 | 作用 | 恢复阶段 | |---|---|---| | redo log LSN | 定位检查点，确定重做起点 | 重做阶段[^3] | | undo log LSN | 关联事务修改顺序，确保回滚一致性 | 回滚阶段 | --- ### **典型崩溃场景示例** 假设事务A（已提交）和事务B（未提交）同时修改行R： 1. **崩溃发生前** - redo log：记录A和B对数据页的物理修改 - undo log：记录B修改前的原始值 2. **恢复过程** - **重做阶段**： redo log同时恢复A和B的修改 → 行R包含A和B的修改结果 - **回滚阶段**： undo log检测到B未提交 → 用undo log撤销B的修改 → 行R仅保留A的修改 > 💎 **结论**： > redo log确保**数据不丢失**，undo log确保**事务原子性**。二者通过LSN和事务状态协同工作，最终达成数据一致性[^1][^2][^4]。 --- ### **相关问题** 1. 为什么MySQL需要先执行redo log再执行undo log？ 2. 在崩溃恢复过程中，如何通过LSN定位检查点(checkpoint)？ 3. undo log的回滚操作是否会再次产生redo log记录？ 4. 如果崩溃发生在undo log写入过程中，恢复流程如何处理？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值