❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+ 7月份开课，已经结课)
原文：https://jfg-mysql.blogspot.com/2025/06/interesting-troubleshooting-crash-filling-then-freeing-disk.html
最近知名MySQL博客J-F Gagné's 发了一篇关于MySQL bug的文章，题目是 Interesting Troubleshooting of a MySQL Crash : filling then freeing the disk 。
这里对这篇文章进行总结，翻译在总结的下方
MySQL 崩溃场景总结 核心问题是，一个大型事务在提交过程中耗尽了磁盘空间，导致 MySQL 崩溃。
“大事务”
一个大型事务开始执行，需要产生大量的二进制日志（binary log）数据。对于超大事务，MySQL 的默认行为是将这部分数据“溢出”到磁盘上的一个临时文件，而不是全部保存在内存中。这种行为解释了您在第一张图表中观察到的，在超过 60 分钟的时间里，数十 GiB 磁盘空间被缓慢持续消耗的现象。
“双倍磁盘空间”问题
当事务准备提交时，MySQL 需要完成二进制日志的写入。在标准的 MySQL 实现中，这个过程需要通过复制临时文件来创建最终的二进制日志文件。这意味着服务器实际上需要临时文件两倍的磁盘空间来完成提交。正是这个操作导致了磁盘被迅速填满，并引发了致命错误。
崩溃
由于磁盘已满，服务器无法将二进制日志刷新（flush）到最终文件，导致刷新阶段失败。由于 binlog_error_action 被设置为 ABORT_SERVER，MySQL 会主动崩溃以防止数据不一致。崩溃后，临时二进制日志文件被立即删除，这解释了图表中数十 GiB 磁盘空间被迅速释放的现象。
崩溃后的恢复挑战 问题并未随着崩溃结束。恢复过程也暴露了进一步需要改进的地方：
回滚延迟
服务器重启后，必须执行崩溃恢复。这包括回滚那个巨大的、未提交的事务，以确保数据完整性。您的日志摘录清楚地显示，从 InnoDB 初始化结束（14:14）到 XA 崩溃恢复完成（42:50）之间存在巨大的时间间隔。这段时间就是用于回滚大型事务所花费的时间。在此漫长的回滚期间，服务器基本处于无响应状态，没有提供任何进度更新，您已经为此提出了 Bug #118358。
二进制日志清理
部分事务也必须从二进制日志文件中清理掉，以确保日志文件处于一致状态。您的扩展图表显示了另一次较小的磁盘空间释放，您认为这是清理二进制日志所致。
您提出的解决方案和 Bug 报告 您敏锐地指出了几个关键点和 MySQL 潜在的改进方向：
Bug #118356：MySQL 尝试提交不适合磁盘的事务，然后崩溃。
您认为 MySQL 应该更智能。它应该在开始提交前就检查是否有足够的可用磁盘空间，从而从一开始就避免崩溃。您承认修复此错误将引入一种提交失败的新场景，这在 MySQL 中是很少见的。
Bug #118358：回滚大事务时，启动过程没有进度迹象。
强调了恢复过程中糟糕的用户体验。服务器看起来像是卡住了，导致管理员感到不确定。您提到，某个 MySQL 分支对此有一个巧妙的解决方案，即在后台执行回滚，从而让服务器能更快地接受连接。
您以一个务实的最佳实践作为总结：虽然通常应避免使用大型事务，但 MySQL 对它们的处理应该更稳健。认为，从根本上避免崩溃（Bug #118356）和消除提交时对额外磁盘空间的需求（Bug #118332），是比仅仅改善回滚过程的日志输出更有价值的投资。
翻译有趣的 MySQL 崩溃排查：磁盘被填满然后又被释放
我最近排查了一个有趣的 MySQL 崩溃问题，觉得值得分享（以及相关的 Bug）。MySQL 在磁盘满的情况下崩溃了，下图展示了磁盘空闲空间的变化曲线：
Y 轴：以 GiB 为单位；
X 轴：以小时为单位。
你能猜到发生了什么吗？
为了确保我们对这张图的理解一致，先解释一下图的含义： 起初，磁盘有几十 GiB 的空闲空间；
然后，在 60 多分钟内，空闲空间被缓慢消耗掉一半以上紧接着磁盘被迅速填满（这部分没有在图中明确显示，此时 MySQL 崩溃）最后，磁盘空间迅速被释放（在崩溃时或刚崩溃之后）。
如果你还不能确定发生了什么，再补充一个可能不那么明显的线索崩溃后释放的磁盘空间数量，正好与之前缓慢消耗的空间一致。还是不确定？那请查看我上一篇文章：
日志总是藏着真相，来看一下当时的错误日志：
2025-xx-yyTzz:12:18.469308Z 1916497 [ERROR] [MY-011072] [Server] Binary logging not possible. Message: An error occurred during flush stage of the commit. 'binlog_error_action' is set to 'ABORT_SERVER'. Server is being stopped.
现在你大概已经猜出来了是一个大事务导致了大量的二进制日志生成这些 binlog 填满了磁盘空间，最终导致了 MySQL 的崩溃，不过在原版 MySQL（而非已做优化的分支中），二进制日志写入其实需要“双倍磁盘空间”！
上图中最后释放的磁盘空间，正好是为写 binlog 时溢出到临时文件而使用的空间。
为什么需要“双倍空间”？（提示：Binlog 写入机制） 如果你还不太理解上述现象，请阅读我上一篇博客，里面解释了大事务的 binlog 是如何写入的（先写临时文件，再复制），以及这如何导致空间占用翻倍。
需要指出的是，如果使用了上一篇文章中所提到的优化方案（在某个 MySQL 分支中），本次崩溃是完全可以避免的。
又一个“COMMIT 失败”的场景！
我认为，MySQL 在启动提交这样的大事务时，应该意识到自己“正在把自己逼入死角”——也就是会把磁盘填满，为此，我提交了 Bug 报告：
🐛 Bug #118356：MySQL 在提交事务时未检查磁盘空间是否足够，最终导致崩溃。
修复这个 Bug 之后，会带来一种 MySQL 以前没有的情况：COMMIT 可能失败。 以前我只见过 COMMIT 在 Group Replication 的冲突检测中失败。
如何复现这个崩溃？ 复现步骤详见上述 Bug 报告和附录 #1，其中包含了观察 binlog 临时文件大小、剩余磁盘空间等命令。但问题还没完：崩溃后的恢复很慢！ 崩溃之后，MySQL 并不会像“魔术一样”顺利启动。
未提交的大事务必须回滚部分写入的事务日志需要从 binlog 中清理 这两项操作都很耗时。我们可以通过扩展版的磁盘空间图观察到回滚延迟和 binlog 清理过程。日志片段也反映了这个延迟过程。
2025-xx-yyTzz:12:18.469308Z 1916497 [ERROR] Binary logging not possible... ABORT_SERVER... ... 2025-xx-yyTzz:12:20.297403Z [InnoDB] InnoDB initialization has started. 2025-xx-yyTzz:14:14.898222Z [InnoDB] InnoDB initialization has ended. 2025-xx-yyTzz:16:02.120982Z [Server] Starting XA crash recovery... 2025-xx-yyTzz:42:50.287434Z [Server] XA crash recovery finished.
我们能看到日志中存在几个小时的“时间空白”——这也促使我提交了另一个 Bug：
🐛 Bug #118358：当回滚大事务时，MySQL 启动日志中没有任何进度提示，用户无法判断当前系统是否卡住。
某个 MySQL 分支的创意改进 该分支（由阿里云工程师宋利兵贡献）引入了一种创新方式优化恢复流程，不再等待大事务回滚完成才启动数据库，而是后台异步回滚事务，同时让 Server 提前对外提供连接服务！
他们在博客中详细介绍了这个优化（Rollback Prepared Transactions Asynchronously During Binlog Crash Recovery），我也在 LinkedIn 上发表了我的看法。
这个优化对 MySQL 来说是有价值的，但对我来说还不是最高优先级。我更希望优先修复其他问题（比如 Bug #118332 中的 binlog 空间使用优化），因此我没有为这个功能提出 Feature Request。
其实，MySQL完全可以不崩溃！既然崩溃后能恢复，不如“直接恢复而不崩溃”
在提交前就拒绝这个事务（Bug #118356）消除提交时额外占用空间的需求（Bug #118332）结尾提醒
通常我们认为，MySQL 最佳实践是避免使用大事务。虽然我建议优化 binlog 写入过程以适配大事务，但这并不表示我鼓励使用大事务。我仍然建议：事务应小于 10 MiB。无论是否遵循此最佳实践，MySQL 都应该让大事务的提交更快、更节省资源。
📎 附录 #1：因磁盘空间不足导致 binlog 拷贝失败的复现实验
实验环境：
AWS 实例：m6id.large（2 vCPU，8 GiB RAM，118 GiB 本地 SSD）
使用 dbdeployer 构建沙箱构造 1 亿行、每行约 4 KiB 的数据更新语句会阻塞，然后因 binlog 空间不足失败。
喜迎上合在天津召开，宣传本地，本地人有责，以下视频感谢 “大腿麻了” 天津著名英语讲师 介绍本地精彩视频 （如有侵权 立即删除）
置顶
说我PG Freezing Boom 讲的一般的那个同学，专帖给你，看看这次可满意
这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
OceanBase Hybrid search 能力测试，平换MySQL的好选择
HyBrid Search 实现价值落地，从真实企业的需求角度分析 ！不只谈技术！
OceanBase 光速快递 OB Cloud “MySQL” 给我，Thanks a lot
从“小偷”开始，不会从“强盗”结束 -- IvorySQL 2025 PostgreSQL 生态大会
被骂后的文字--技术人不脱离思维困局，终局是个 “死” ？ ! ......
个群2025上半年总结，OB、PolarDB, DBdoctor、爱可生、pigsty、osyun、工作岗位等
从MySQL不行了，到乙方DBA 给狗，狗都不干？ 我干呀！
SQL SERVER 2025发布了， China幸亏有信创！
MongoDB 麻烦专业点，不懂可以问，别这么用行吗 ! --TTL
PostgreSQL 新版本就一定好--由培训现象让我做的实验
删除数据“八扇屏” 之 锦门英豪 --我去-BigData！
写了3750万字的我，在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》
疯狂老DBA 和 年轻“网红” 程序员 --火星撞地球-- 谁也不是怂货
和架构师沟通那种“一坨”的系统，推荐只能是OceanBase，Why ?
OceanBase 相关文章
写了3750万字的我，在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》
OceanBase 6大学习法--OBCA视频学习总结第六章
OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计
OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计
OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装
OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎
OceanBase 架构学习--OB上手视频学习总结第二章 （OBCA）
OceanBase 6大学习法--OB上手视频学习总结第一章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
MongoDB 相关文章
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅，上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗？在次补刀MongoDB 双机热备
MONGODB ---- Austindatabases 历年文章合集
PolarDB 已经开放的课程
PolarDB 非官方课程第八节--数据库弹性弹出一片未来--结课
PolarDB 非官方课程第七节--数据备份还原瞬间完成是怎么做到的--答题领奖品
PolarDB 非官方课程第六节--数据库归档还能这么玩--答题领奖品
PolarDB 非官方课程第五节--PolarDB代理很重要吗？--答题领奖品
PolarDB 非官方课程第四节--PG实时物化视图与行列数据整合处理--答题领奖品
PolarDB 非官方课程第三节--MySQL+IMCI=性能怪兽--答题领奖品
PolarDB 非官方课程第二节--云原生架构与特有功能---答题领奖品
PolarDB 非官方课程第一节-- 用户角度怎么看PolarDB --答题领奖品
免费PolarDB云原生课程，听课“争”礼品，重塑云上知识，提高专业能力
PolarDB 相关文章
这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
用MySQL 分区表脑子有水！从实例，业务，开发角度分析 PolarDB 使用不会像MySQL那么Low
MySQL 和 PostgreSQL 可以一起快速发展，提供更多的功能？
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密（谁是绵羊，谁是怪兽）
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 相关文章
说我PG Freezing Boom 讲的一般的那个同学专帖给你看这次可满意
PostgreSQL Hybrid能力岂非“小趴菜”数据库可比 ？
PostgreSQL 新版本就一定好--由培训现象让我做的实验
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 （翻译）
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
PostgreSQL 添加索引导致崩溃，参数调整需谨慎--文档未必完全覆盖场景
PostgreSQL SQL优化用兵法，优化后提高 140倍速度
PostgreSQL 运维的难与“难” --上海PG大会主题记录
PostgreSQL 什么都能存，什么都能塞 --- 你能成熟一点吗？
全世界都在“搞” PostgreSQL ，从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
病毒攻击PostgreSQL暴力破解系统，防范加固系统方案（内附分析日志脚本）
PostgreSQL 远程管理越来越简单，6个自动化脚本开胃菜
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
PostgreSQL 字符集乌龙导致数据查询排序的问题，与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 （音译）
PostgreSQL 玩PG我们是认真的，vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”，“架构师”，滥用PG 你们滚出 ！（附送定期清理连接脚本）
MySQL相关文章
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊
MYSQL --Austindatabases 历年文章合集
临时工访谈系列
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
SQL SERVER 系列
SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗
