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 的。

1 redo log

和大多数关系型数据库一样，InnoDB 记录了对数据文件的物理更改，并保证总是日志先行。

也就是所谓的 WAL（Write-Ahead Logging），即在持久化数据文件前，保证之前的 redo log 已经写到磁盘。

Mysql 的每一次更新并没有每次都写入磁盘，InnoDB 引擎会先将记录写到 redo log 里，并更新到内存中，然后再适当的时候，再把这个记录更新到磁盘。

提到了两个重要的日志，我觉得这里有必要贴一下 InnoDB 的存储结构图，对其有一个整体的认识：

如果下面看的各种空间懵逼了，建议回来看一眼这个图。

1.1 redo log 是啥？

当数据库对数据做修改的时候，需要把数据页从磁盘读到 buffer pool 中，然后在 buffer pool 中进行修改。

那么这个时候 buffer pool 中的数据页就与磁盘上的数据页内容不一致，我们称 buffer pool 的数据页为 dirty page 脏数据。

感觉就像先拷贝一份数据，对拷贝的数据进行修改，修改完毕后再覆盖到原数据。

这里也可以看出，所有的更新操作都是现在 dirty page 中进行的。

如果这个时候发生非正常的 DB 服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机 io），也就是会发生数据丢失。

如果这个时候，能够在有一个文件，当 buffer pool 中的 dirty page 变更结束后，把相应修改记录记录到这个文件（注意，记录日志是顺序 IO）。

那么当 DB 服务发生 crash 的情况，恢复 DB 的时候，也可以根据这个文件的记录内容，重新应用到磁盘文件，数据保持一致。

这个文件就是 redo log ，用于记录数据修改后的记录，顺序记录。

我理解的，redo log 就是存放 dirty page 的物理空间。

1.2 何时产生 & 释放？

在事务开始之后就产生 redo log，redo log 的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入 redo log 文件中。

当对应事务的脏页写入到磁盘之后，redo log 的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

1.3 如何写？

redo log 文件以 ib_logfile[number] 命名，并以顺序的方式写入文件文件，写满时则回溯到第一个文件，进行覆盖写。

如图所示：

• write pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；

• checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；

write pos 和 checkpoint 之间还空着的部分，可以用来记录新的操作。

如果 write pos 追上 checkpoint，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。

redo log 文件是循环写入的，在覆盖写之前，总是要保证对应的脏页已经刷到了磁盘。

在非常大的负载下，redo log 可能产生的速度非常快，导致频繁的刷脏操作，进而导致性能下降。

如果可预期会有这样的场景，我们建议调大 redo log 文件的大小。可以做一次干净的 shutdown，然后修改 redo log 配置，重启实例。

参考：
Http://mysql.taobao.org/monthly/2015/05/01/

1.4 相关配置

默认情况下，对应的物理文件位于数据库的 data 目录下的 ib_logfile1、ib_logfile2。

innodb_log_group_home_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2
# 关于文件的大小和数量，由一下两个参数配置
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1

1.5 其他

redo log 有一个缓存区 Innodb_log_buffer，默认大小为 8M，Innodb 存储引擎先将重做日志写入 innodb_log_buffer 中。

然后会通过以下三种方式将 innodb 日志缓冲区的日志刷新到磁盘：

1、Master Thread 每秒一次执行刷新 Innodb_log_buffer 到重做日志文件；
2、每个事务提交时会将重做日志刷新到重做日志文件；
3、当 redo log 缓存可用空间少于一半时，重做日志缓存被刷新到重做日志文件；

有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。

CrashSafe 能够保证 MySQL 服务器宕机重启后：

• 所有已经提交的事务的数据仍然存在

• 所有没有提交的事务的数据自动回滚

2 binlog

如前文所讲，MySQL 整体可以分为 Server 层和引擎层。

其实，redo log 是属于引擎层的 InnoDB 所特有的日志，而 Server 层也有自己的日志，即 binlog（归档日志）。

2.1 binlog 是什么？

逻辑格式的日志，可以简单认为就是执行过的事务中的 sql 语句。

但又不完全是 sql 语句这么简单，而是包括了执行的 sql 语句（增删改）反向的信息。

也就意味着 delete 对应着 delete 本身和其反向的 insert；update 对应着 update 执行前后的版本的信息；insert 对应着 delete 和 insert 本身的信息。

2.2 何时产生 & 释放？

事务提交的时候，一次性将事务中的 sql 语句按照一定的格式记录到 binlog 中。因此，对于较大事务的提交，可能会变得比较慢一些。

binlog 的默认是保持时间由参数 expire_logs_days 配置，也就是说对于非活动的日志文件，在生成时间超过配置的天数之后，会被自动删除。

2.3 和 redo log 的区别

1、redo log 是 InnoDB 引擎特有的，binlog 是 MySQL 的 Server 层实现，所有引擎都可以使用；

2、内容不同：redo log 是物理日志，记录的是在数据页上做了什么修改,是正在执行中的 dml 以及 ddl 语句；

而 binlog 是逻辑日志，记录的是语句的原始逻辑，已经提交完毕之后的 dml 以及 ddl sql 语句，如「给 ID=2 的这一行的 c 字段加 1」；

3、写方式不同：redo log 是循环写的，空间固定；binlog 是可以一直追加写的，一个文件写到一定大小后，会继续写下一个，之前写的文件不会被覆盖；

4、作用不同：redo log 主要用来保证事务安全，作为异常 down 机或者介质故障后的数据恢复使用，binlog 主要用来做主从复制和即时点恢复时使用；

5、另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。

参考：
http://www.importnew.com/28039.html

3 数据更新事务流程

有了对这两个日志的概念性理解，我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。

1、执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

对应到上面讲的，就是将数据加载到脏数据中。

2、执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

3、引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。

4、执行器生成这个操作的 binlog，并把 binlog 写入磁盘；

5、执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

两阶段提交

上面处理 redo log 和 binlog 看着是不是有点懵逼？

其实这就是所谓的两阶段提交，即 COMMIT 会被自动的分成 prepare 和 commit 两个阶段。

MySQL 在 prepare 阶段会生成 xid，然后会在 commit 阶段写入到 binlog 中。在进行恢复时事务要提交还是回滚，是由 Binlog 来决定的。

由上面的二阶段提交流程可以看出，通过两阶段提交方式保证了无论在任何情况下，事务要么同时存在于 redo log 和 binlog 中，要么两个里面都不存在。

这样就可以保证事务的 binlog 和 redo log 顺序一致性。一旦阶段 2 中持久化 binlog 完成，就确保了事务的提交。

此外需要注意的是，每个阶段都需要进行一次 fsync 操作才能保证上下两层数据的一致性。

PS：记录 Binlog 是在 InnoDB 引擎 Prepare（即 Redo Log 写入磁盘）之后，这点至关重要。

另外需要注意的一点就是，SQL 语句产生的 Redo 日志会一直刷新到磁盘（master thread 每秒 fsync redo log），而 Binlog 是事务 commit 时才刷新到磁盘，如果 binlog 太大则 commit 时会慢。

参考：
http://www.ywnds.com/?p=7892

举个例子

Bin log 用于记录了完整的逻辑记录，所有的逻辑记录在 bin log 里都能找到，所以在备份恢复时，是以 bin log 为基础，通过其记录的完整逻辑操作，备份出一个和原库完整的数据。 

如 redo log 执行了 update t set status = 1，此时原库的数据 status 已更新为 1，而 bin log 写入失败，没有记录这一操作，后续备份恢复时，其 status = 0，导致数据不一致）。 

其核心就是， redo log 记录的，即使异常重启，都会刷新到磁盘，而 bin log 记录的， 则主要数据库逻辑操作，主要用于备份恢复。

一个完整的交易过程：

账本记上卖一瓶可乐（redo log 为 prepare 状态），然后收钱放入钱箱（bin log 记录）然后回过头在账本上打个勾（redo log 置为commit），给人可乐，表示一笔交易结束。 

如果收钱时交易被打断，回过头来整理此次交易，发现只有记账没有收钱，则交易失败，删掉账本上的记录（回滚）；

如果收了钱后被终止，然后回过头发现账本有记录（prepare）而且钱箱有本次收入（bin log），则继续完善账本（commit），本次交易有效。

4 如何恢复任意时间的数据？

当需要恢复到指定的某一秒时，比如 2018.11.23 14.23.45 有一次数据库误操作，需要找回数据，那你可以这么做：

1、首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上 11.22 日的一个备份，从这个备份恢复到临时库；

2、然后，从备份的时间点开始，将备份的 binlog 依次取出来，重放到中午误删表之前的那个时刻。

这样你的临时库就跟误删之前的线上库一样了，然后你可以把表数据从临时库取出来，按需要恢复到线上库去。

当遇到 crash 时，恢复的过程也非常简单：

1、恢复过程中会扫描最后一个 binlog 文件，提取其中的 xid； 

2、重做检查点以后的 redo 日志，搜集处于 prepare 阶段的事务链表，将事务的 xid 与 binlog 中的 xid 对比。

若存在，说明事务记录到 binlog 成功，但是最终未 commit 成功，则提交，否则就回滚；

这里要结合上面的两段提交一起看，才能理解得比较透彻。

总结一下，基本顶多会出现下面是几种情况：

• 当事务在 prepare 阶段 crash，数据库 recovery 的时候该事务未写入 binlog 并且 redo log 未提交，将该事务 rollback。

• 当事务在 binlog 阶段 crash，此时日志还没有成功写入到磁盘中，启动时会 rollback 此事务。

• 当事务在 binlog 日志已经 fsync 到磁盘后 crash，但是 InnoDB 没有来得及 commit，此时 MySQL 数据库 recovery 的时候将会读出 binlog 中的 xid，然后告诉 InnoDB 提交这些 xid 的事务，InnoDB 提交完这些事务后会回滚其它的事务，使 redo log 和 binlog 始终保持一致。

我再来说下自己的理解

1、prepare 阶段； 2、写binlog 阶段；3、commit 阶段；

当在2之前崩溃时

重启恢复：后发现没有commit，回滚。

备份恢复：没有 binlog 。一致。

当在3之前崩溃

重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。

备份：有binlog，一致。

总结起来说就是如果一个事务在 prepare 阶段中落盘成功，并在 MySQL Server 层中的 binlog 也写入成功，那这个事务必定 commit 成功。

总结

介绍了 MySQL 里面最重要的两个日志，即物理日志 redo log 和逻辑日志 binlog。

最好能够理解这两种日志的作用分别是什么，自己能够理清楚事物的提交流程。

课后题目 & 评论区精华

这次评论区精彩有点多！

“MySQL怎么恢复到任意一秒的状态”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站，小编将为大家输出更多高质量的实用文章！