Marathonk 最近的时间轴更新
Marathonk

Marathonk

V2EX 第 461279 号会员,加入于 2019-12-25 16:57:16 +08:00
Marathonk 最近回复了
@liuxingchina 其实我之前的主要疑问也在这里,如果 1 完成 2 还没做,同时 buffer pool 中的数据被持久化到磁盘了,这时数据库崩溃了,那岂不是写入了脏数据进来?
后来查阅了很多资料,其实 Innodb 内部实现还是很复杂的,简单的逻辑是会保证 undo log 和数据页的修改都写入 redo log 并且落盘后,前者才会落盘,这也是保证原子性的基础。
@koor 一件代发,他们不囤货,不知道货还有没有,只有你下单后他们去让代发商发货时才知道没货了,这时候一般会让你取消订单。淘宝遇到这种会赔百分之几来着,我上次索赔了,然后店铺短信轰炸我了哈哈哈
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 时以一个整体进行重放,要么全部重放,要么全部丢弃。
期待开源,mark 一下
57 天前
回复了 Marathonk 创建的主题 问与答 区块链毕设方向推荐
@James1847 嗯嗯好的,我了解一下
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2240 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 61ms · UTC 16:13 · PVG 00:13 · LAX 08:13 · JFK 11:13
♥ Do have faith in what you're doing.