看到这个题目是不是觉得数据库再也不用担心服务器 crash 了?
那我们需要学习为什么可以这么做?以及如何做?
即为什么可以恢复到任意时间点?如何恢复到任意时间点?
为什么有了 binlog 还需要 redo log?
事务是如何提交的?事务提交先写 binlog 还是 redo log?如何保证这两部分的日志做到顺序一致性?
为了保障主从复制安全,故障恢复是如何做的?
上一次课我们学习了一条 select
语句的全部执行过程,那么今天我们就从一条 update
语句开始。
mysql> update T set c=c+1 where ID=2;
其实执行流程和查询流程一致,只是最后执行器执行的是找到这条数据,并进行更新。
另外,更新过程还涉及到一个重要的日志模块,即 redo log
(重做日志)和 binlog
(归档日志)。
我个人是只听过 binlog 的。
redo log
和大多数关系型数据库一样,InnoDB 记录了对数据文件的物理更改,并保证总是日志先行。
也就是所谓的 WAL(Write-Ahead Logging),即在持久化数据文件前,保证之前的 redo 日志已经写到磁盘。
MySQL 的每一次更新并没有每次都写入磁盘,InnoDB 引擎会先将记录写到 redo log 里,并更新到内存中,然后再适当的时候,再把这个记录更新到磁盘。
这里有必要贴一下 InnoDB 的存储结构图:
如果下面看的各种空间懵逼了,建议回来看一眼这个图。
redo log 是啥
当数据库对数据做修改的时候,需要把数据页从磁盘读到 buffer pool 中,然后在 buffer pool 中进行修改,那么这个时候 buffer pool 中的数据页就与磁盘上的数据页内容不一致,我们称 buffer pool 的数据页为