020 MySQL中Redo Log、The Binary Log和2阶段提交

专注_每天进步一点点

已于 2022-03-31 16:15:25 修改

阅读量243

点赞数

分类专栏： 07MySQL 文章标签： MySQL Redo Log Binary Log

于 2022-03-31 11:12:23 首次发布

原文链接：https://zhuanlan.zhihu.com/p/98778890?utm_source=ZHShareTargetIDMore

版权

07MySQL 专栏收录该内容

28 篇文章 3 订阅

订阅专栏

学软件技术，读第一手资料，去官方网站：MySQL 5.7参考手册

也可以看看比较经典的书籍，如《高性能MySQL》等

假设你执行了一条 sql 语句：

update user set age = 18 where user_id = 345981

MySQL 会直接去磁盘修改数据吗？

明显不会，磁盘IO太慢了，如果每个请求过来 MySQL 都要写磁盘，磁盘肯定扛不住。

那就写内存？把数据从磁盘load到内存，然后修改内存里的数据。

也不行，万一掉电了，内存就没了，数据就再也找不回来了。

这其实是很多中间件都会遇到的问题，一个中间件做的再怎么分布式，怎么高可靠，都会遇到这个问题：

数据来了，写磁盘，还是写内存？

写磁盘，嫌太慢？写内存，又不安全？

MySQL 的解决方案是：既写磁盘又写内存。

数据写内存，另外再往磁盘写 redo log.

1、redo log 是什么

在执行上面这条 sql 语句时，MySQL 会判断内存中有没有 user_id = 345981 的数据，没有，则去磁盘找到这条数据所在的「页」，把整页数据都加载到内存，然后找到 user_id = 345981 的 row 数据，把内存中这行数据的 age 设置为 18。

这时，内存的数据是新的、正确的，而磁盘数据是旧的、过时的，所以我们称这时的磁盘对应的页数据，为「脏页」。

这里补充一个知识点：MySQL 是按页为单位来读取数据的，一个页里面有很多行记录，从内存刷数据到磁盘，也是以页为单位来刷。

这时候如果掉电了，数据就没了，于是 MySQL 把你对页修改了什么内容，记录了下来，保存到磁盘，也就是redo log。

写完 redo log，MySQL 就认为事务提交成功了，数据持久化了（ACID的D），然后在空闲的时候，再把内存的数据刷到磁盘。

如果在内存数据刷到磁盘之前，MySQL 掉电了，怎么办？

这时只需要在重启后，把「脏页」load 到内存，然后应用 redo log，脏页就变成「干净页」了。

你会说，万一我写内存成功，但是把 redo log 写到磁盘失败了呢？这点后面我们在讨论「两阶段提交」时再讨论。

你还会说，redo log 还是要写磁盘，那不还是很慢？

并不是，把 redo log 写到磁盘，比一般的写磁盘要快，原因有：

一般我们写磁盘，都是「随机写」，而 redo log，是「顺序写」
MySQL 在写 redo log 上做了优化，比如「组提交」

这些后面我们会陆续展开。

1.1 redo log 怎么存储

MySQL 官方文档有几句话：

the redo log encodes requests to change table data that result from SQL statements or low-level API calls.
The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions.
By default, the redo log is physically represented on disk by two files named ib_logfile0 and ib_logfile1.
MySQL writes to the redo log files in a circular fashion.

从这几句话，我们大致可以get到：

redo log 记录了 sql 语句以及其他 api，对表数据产生的变化，也就是说，redo log 记录的是数据的物理变化，这也是它和后面要讲的 binlog 一个最大的区别，binlog 记录的是数据的逻辑变化，这也是为什么 redo log 可以用来 crash recovery，而 binlog 不能的原因之一
redo log 是存储在磁盘的，用于 crash recovery 后修正数据的，也就是我们常说的故障恢复，比如掉电，宕机等等
redo log 默认有两个文件
redo log 是循环写的（circular）

根据最后两个小点，我们大致可以画出这样一个图：

redo log

另外还有两个参数：

innodb_log_file_size：设置每个 redo log 文件的大小，默认是 50331648 byte，也就是 48 MB
innodb_log_files_in_group：设置 redo log 文件的数量，默认是 2，最大值是 100

我们常说事务具有 ACID 四个特性，其中 D（durability），数据持久性，意味着，一旦事务提交，它的状态就必须保持提交，不能回滚，哪怕你系统宕机了、奔溃了，你也要想办法把事务做到提交，把数据给我保存进去：

Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or crash).

这确实很严格，但看起来也很好实现，就是每次都把数据写到磁盘，然后再告诉客户端，事务提交成功了。

但如果我要追求高性能呢？我要把数据写到内存呢？

所以我们说，innodb 在实现高性能写数据的同时，利用 redo log，实现了事务的持久性。

2、binlog

讲完了 redo log，我们再来聊聊 binlog。

还是这一条 update 语句：

update user set age = 18 where user_id = 345981

在这条 update 语句执行的时候，除了生成 redo log，还会生成 binlog。

binlog 和 redo log 有很多不同，有一点是一定要知道的，就是 redo log 只是 innodb 存储引擎的功能，而 binlog 是 MySQL server 层的功能，也就是说，redo log 只在使用了 innodb 作为存储引擎的 MySQL 上才有，而 binlog，只要你是 MySQL，就会有。