MySQL双日志-redolog/binlog

InnoDB引擎的redo log日志

解决什么问题？

我们每次更新数据如果都要直接写到硬盘存储的话，如果更新数据频繁的话，整个过程的Io成本和查找成本都会很高(比方说每次启动磁盘，平均的寻找数据时间将会很长)

怎么解决？

引入了redo log，redo就相当于一个缓存，它的关键点就是先写日志，在写到磁盘，这样的效率就会大大提高，如果更新频繁的话，先把这些更新的数据写到redo，当空闲下来在写到硬盘中去。

redo文件

作用

redo log是物理日志，记录的是在某个数据页上做了什么修改

大小有限

redo的文件大小是有限的，如何保持有限的内存，对付可能无限的更新操作，它会把写入硬盘的数据擦除，这样就可以循环使用了。

原理

内部类似一个双指针，一个指针记录，更新的操作，一个指针记录擦除的位置，两个指针之间的部分，就是还剩余的部分。

可能出现的问题

1.但是要是更新指针追上了擦除指针会发生什么？

这个时候更新操作就会停止，先去执行擦除操作，让剩余空间出现

2.异常重启

如果数据库异常重启了，redo就会刷新到硬盘，之前的提交记录没有丢失，这个能力称为crash-safe

MySQL的binlog

MySQL的sever层也有自己的日常binlog(归档日志)

作用

首先它是server层特有的，所以不管你用了什么引擎，这个日志都是存在的

binlog是逻辑日志，记录的是这个语句的原始逻辑，比方说在zx表中给id为2的，age+1，所有的更新操作都会在这个日志中找到。

备份恢复的 时候，就是以binlog为基础

两种模式

Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。

由于有两个日志，那么保持如何保持一致性呢？

两阶段提交

就是类似事务的方式，要么都成功要么都失败