354 字
2 分钟
MySQL-redolog
91%
全部章节
- 1 MySQL共享锁和排他锁的区别
- 2 数据库ACID四大特性
- 3 MVCC-多版本并发控制
- 4 MySQL全局锁,表级锁,行级锁
- 5 MySQLbinlog,redolog和undolog
- 6 MySQL索引类型有哪些
- 7 MySQL-VARCHAR支持的最大长度
- 8 MySQL事务隔离级别
- 9 MySQL中的数据排序是怎么实现的
- 10 MySQL中几种count的区别
- 11 MySQL中CHAR和VARCHAR的区别
- 12 MySQL事务的两阶段提交是什么
- 13 MySQL中发生死锁如何解决
- 14 搭建MySQL主从服务器
- 15 如何处理MySQL的主从同步延迟
- 16 什么是MySQL的主从同步机制
- 17 MySQL中如何解决深度分页问题
- 18 分库分表场景
- 19 MySQL联合索引失效情况
- 20 MySQL-binlog
- 21 MySQL-redolog 阅读中
- 22 MySQL-relaylog(中继日志)
- 23 MySQL-undolog(回滚日志)

Redo Log(实现持久化)
在InnoDB存储引擎中,大部分Redo Log记录的是物理日志,也就是对特定数据页进行的具体修改。 那么为啥要称呼它为大部分是物理日志呢?是因为Redo Log系统由两部分构成:
- 一是位于内存中的重做日志缓冲区(redolog buffer),这部分信息容易因为断电等原因丢失。
- 二是保存于磁盘上的重做日志文件(redolog file)提供持久化存储
引入redo log的必要性
尽管buffer pool确实极大提升了数据库操作的性能,但是由于它基于内存的特点,存在着固有的不稳定性,一旦发生系统崩溃或断电等故障,内存中的数据就可能会丢失。为了避免这种情况,Redo Log应运而生。 通过与buffer pool和change buffer协同工作,redolog负责记录所有尚未同步到磁盘的更改操作,确保即使发生故障重启以后也能恢复这些更新,直到相关页面被最终安全地写入到磁盘为止。

redo log和undo log之间的差异
- Redo Log专注于 记录事务完成后的新状态,也就是变更后的值
- Undo Log用来追踪事务开始前的原始状态,保存的是变更前的旧值




崩溃恢复

发现错误或想要改进这篇文章?
在 GitHub 上编辑此页 MySQL-redolog
相关文章
按系列 / 标签 / 分类推荐