MySQL的日志模块

一、redo log

MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

(“先写日志” 也是先写磁盘，只是写日志是顺序写盘，速度很快。)

redo log 记录这个页 “做了什么改动”。（只是记录了，但是没有实际更新到数据库里面）

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB。从头开始写，写到末尾就又回到开头循环写。

write pos 是当前记录的位置。

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

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

二、binlog（归档日志）

binlog的三个模式：ROW STATEMENT MIXED

打开binlog

（如何打开看B站那个视频，配置是 log_bin）

查看binlog日志文件

$ show binary logs

使用binlog恢复数据有两种方式   ① 通过事务的时间点来实现

                                                    ② 通过事务的位置来实现【具体看binlog文件就可以知道】

binlog记录了所有操作语句的逻辑，比如记录这 2022年9月18号下午16:20:00提交了一个语句，将某某表的某个字段的值变为2。

三、实现数据恢复

当需要恢复到指定的某一秒时，比如某天下午两点发现中午十二点有一次误删表，需要找回数据，那你可以这么做：

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

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

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

四、update逻辑

写入redo log，处于prepare阶段，写入binlog，提交事务处于commit状态

设计这种逻辑，是为了保证redo log 和binlog的一致性，保证在恢复数据的时候与业务数据一致，不会出现误差。