1
Marathonk OP 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 时以一个整体进行重放,要么全部重放,要么全部丢弃。 |
2
liuxingchina 2021-12-24 15:50:13 +08:00 1
1.磁盘加载数据到 buffer pool
2.写入 undo log 记录旧数据用于回滚 3.写入 redo log buffer 4.redo log 刷盘 5.写入 bin log 6.写入 commitId 到 redo log 7.事务提交 |
3
Marathonk OP @liuxingchina 其实我之前的主要疑问也在这里,如果 1 完成 2 还没做,同时 buffer pool 中的数据被持久化到磁盘了,这时数据库崩溃了,那岂不是写入了脏数据进来?
后来查阅了很多资料,其实 Innodb 内部实现还是很复杂的,简单的逻辑是会保证 undo log 和数据页的修改都写入 redo log 并且落盘后,前者才会落盘,这也是保证原子性的基础。 |