MySQL-redo log 和 binlog

redo log部分

为什么需要redo log？

简单的说，如果每次更新数据库的操作，都去更新磁盘的话，开销是很大的。通过引入redo log日志，其中记录了每次更新的操作明细，在系统不繁忙的时候，再更新到磁盘中，可以节省开销。

最新修改：
redo log 最主要的作用就是用于数据库异常宕机的恢复工作。
假如数据库永远不会发生异常宕机，那么其实根本不需要redo log，因为innodb中有线程不断的做把脏页刷新到磁盘的工作，数据库如果一直不宕机，就不会出现问题。

被划掉的线的部分的理解的产生是因为在极客时间《mysql实战45讲》的课程中，老师就是这么说的，所以就直接这么写了。但在后续的学习中，我查阅了《MySQL技术内幕-InnoDb存储引擎的实现》这本书，发现了最开始的理解并不准确，所以进行了修改。

redo log的实现

redo log是一个环，大小是固定的，文件个数和大小是可以配置的。其中有两个指针，write和checkpoint，分别对应可以写入的位置，和已经刷新到磁盘的位置。

当write追上了checkpoint，说明已经没有空闲的位置可以写入了，就需要刷新一下，保证有位置可以写入。

---

binlog部分

redo log 和 binlog的区别

1. redo log是 innodb存储引擎特有的；binlog是server层，属于共有的
2. redo log是物理日志，记录在某个数据页的修改；binlog是逻辑日志
3. redo log是一个环，循环写；binlog是追加写，不会覆盖以前的日志
4. redo log用于异常重启恢复；binlog用于备份

---

一条更新语句的执行过程（redo log和binlog的配合）

1. 执行器调用引擎接口写入新数据
2. 引擎把更新操作记录到 redo log中，此时redo log为prepare状态
3. 执行器生成这个操作的binlog，并写入磁盘
4. 执行器调用引擎的事务提交接口，引擎把redo log的状态改为commit

微信图片_20200630172321.jpg

prepare和binlog是如何保证一致性的?

1. prepare阶段
2. binlog写入阶段
3. commit阶段

在2阶段之前崩溃时：

• 重启恢复：发现没有commit，回滚
• 备份恢复：没有binlog

保持了一致性

在3阶段之前崩溃时：

• 重启恢复：虽没有commit，但是binlog有，并且一致，所以恢复
• 备份恢复：有binlog

保持了一致性

---

最佳实践部分

1. innodb_flush_log_at_trx_commit 参数建议设置为1，每次更新操作，redo log都会刷新到磁盘
2. sync_binlog 参数建议设置为1，每次更新操做，binlog会刷新到磁盘