MySQL实战 | 02-MySQL 如何恢复到半个月内任意一秒的状态？

原文链接：MySQL是如何做到可以恢复到任意一秒状态的？

看到这个题目是不是觉得数据库再也不用担心服务器 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 的数据页为