Marathonk 最近的时间轴更新 Marathonk 最近的时间轴更新 |
MarathonkV2EX 第 461279 号会员，加入于 2019-12-25 16:57:16 +08:00 |
| InnoDB 中 redo log 和 undo log 以及数据页的修改顺序到底是怎样的？ 问与答 • Marathonk • 144 天前 • 最后回复来自 Marathonk | 3 |
| 奇了怪了，为什么楼下那篇帖子点不开？你们都能点开吗？ 新手求助 • Marathonk • 172 天前 • 最后回复来自 v2tudnew | 11 |
| 想问一下有没有把 tcpdump 这种流量捕捉封装成 web 可交互操作的项目 问与答 • Marathonk • 2020-11-17 14:12:39 PM • 最后回复来自 Marathonk | 3 |
| 求推荐可视化操作的流量捕获和回放工具 程序员 • Marathonk • 2020-11-07 16:32:33 PM • 最后回复来自 toomlo | 1 |
| xdm，有没有比较好用的公司网站模板或者源码项目推荐 问与答 • Marathonk • 2020-11-07 11:07:00 AM |
| 几个华为云名额，感兴趣可以看下 问与答 • Marathonk • 2020-11-06 22:57:13 PM • 最后回复来自 OldActorsSmile | 3 |
| 项目需要，请问大家有什么网络设备仿真项目推荐吗？ 程序员 • Marathonk • 2020-11-02 15:00:14 PM • 最后回复来自 Marathonk | 9 |
Marathonk 最近回复了
64 天前 回复了 cmichael 创建的主题 › macOS › macwk 的 app 安装非得搞成命令行的形式，是何用意？ |
@macwk 老哥，为啥 macwk502 了，是出什么事情了吗
144 天前 回复了 Marathonk 创建的主题 › 问与答 › InnoDB 中 redo log 和 undo log 以及数据页的修改顺序到底是怎样的？ |
@liuxingchina 其实我之前的主要疑问也在这里，如果 1 完成 2 还没做，同时 buffer pool 中的数据被持久化到磁盘了，这时数据库崩溃了，那岂不是写入了脏数据进来？
后来查阅了很多资料，其实 Innodb 内部实现还是很复杂的，简单的逻辑是会保证 undo log 和数据页的修改都写入 redo log 并且落盘后，前者才会落盘，这也是保证原子性的基础。
后来查阅了很多资料，其实 Innodb 内部实现还是很复杂的，简单的逻辑是会保证 undo log 和数据页的修改都写入 redo log 并且落盘后，前者才会落盘，这也是保证原子性的基础。
145 天前 回复了 v2byy 创建的主题 › 问与答 › 天猫超市承诺送货上门，未上门送 20 元猫超卡 |
@koor 一件代发，他们不囤货，不知道货还有没有，只有你下单后他们去让代发商发货时才知道没货了，这时候一般会让你取消订单。淘宝遇到这种会赔百分之几来着，我上次索赔了，然后店铺短信轰炸我了哈哈哈
145 天前 回复了 Marathonk 创建的主题 › 问与答 › InnoDB 中 redo log 和 undo log 以及数据页的修改顺序到底是怎样的？ |
MySQL 中的 Undo Log 严格的讲不是 Log ，而是数据，因此他的管理和落盘都跟数据是一样的：
Undo 的磁盘结构并不是顺序的，而是像数据一样按 Page 管理 Undo 写入时，也像数据一样产生对应的 Redo Log
Undo 的 Page 也像数据一样缓存在 Buffer Pool 中，跟数据 Page 一起做 LRU 换入换出，以及刷脏。
Undo Page 的刷脏也像数据一样要等到对应的 Redo Log 落盘之后
之所以这样实现，首要的原因是 MySQL 中的 Undo Log 不只是承担 Crash Recovery 时保证 Atomic 的作用，更需要承担 MVCC 对历史版本的管理的作用，设计目标是高事务并发，方便的管理和维护。因此当做数据更合适。
但既然还叫 Log ，就还是需要有 Undo Log 的责任，那就是保证 Crash Recovery 时，如果看到数据的修改，一定要能看到其对应 Undo 的修改，这样才有机会通过事务的回滚保证 Crash Atomic 。标准的 Undo Log 这一步是靠 WAL 实现的，也就是要求 Undo 写入先于数据落盘。而 InnoDB 中 Undo Log 作为一种特殊的数据，这一步是通过 redo 的 min-transaction 保证的，简单的说就是数据的修改和对应的 Undo 修改，他们所对应的 redo log 被放到同一个 min-transaction 中，同一个 min-transaction 中的所有 redo log 在 Crash Recovery 时以一个整体进行重放，要么全部重放，要么全部丢弃。
Undo 的磁盘结构并不是顺序的，而是像数据一样按 Page 管理 Undo 写入时，也像数据一样产生对应的 Redo Log
Undo 的 Page 也像数据一样缓存在 Buffer Pool 中，跟数据 Page 一起做 LRU 换入换出，以及刷脏。
Undo Page 的刷脏也像数据一样要等到对应的 Redo Log 落盘之后
之所以这样实现，首要的原因是 MySQL 中的 Undo Log 不只是承担 Crash Recovery 时保证 Atomic 的作用，更需要承担 MVCC 对历史版本的管理的作用，设计目标是高事务并发，方便的管理和维护。因此当做数据更合适。
但既然还叫 Log ，就还是需要有 Undo Log 的责任，那就是保证 Crash Recovery 时，如果看到数据的修改，一定要能看到其对应 Undo 的修改，这样才有机会通过事务的回滚保证 Crash Atomic 。标准的 Undo Log 这一步是靠 WAL 实现的，也就是要求 Undo 写入先于数据落盘。而 InnoDB 中 Undo Log 作为一种特殊的数据，这一步是通过 redo 的 min-transaction 保证的，简单的说就是数据的修改和对应的 Undo 修改，他们所对应的 redo log 被放到同一个 min-transaction 中，同一个 min-transaction 中的所有 redo log 在 Crash Recovery 时以一个整体进行重放，要么全部重放，要么全部丢弃。
153 天前 回复了 zqli92 创建的主题 › 程序员 › 重构了整个网站，程序员实时 Markdown 聊天，欢迎各位体验 |
期待开源，mark 一下
Select Language