Mysql日志学习笔记

redo log

WAL全称Write-Ahead Logging，先写日志，再写磁盘。
当一条记录要更新，InnoDb会先把记录写redo log中，更新内存，完成操作，InnoDb会在适当的时候将操作更新进磁盘中。

Innodb的redo log是固定大小，如果写满，会暂停其他操作，先腾出空间，在继续向redolog中写。redolog是顺序写，虽然redo log也在磁盘上，但是比直接更新数据的随机IO省时，效率更高。

write pos是当前位置，一边写一边后移，checkpoint是要擦出的位置，擦出前将记录更新到数据文件。

因此有crash-safe。

binlog

binlog是server层的，而redolog是innodb引擎层的。
因此binlog所有引擎都能使用。

redolog是物理日志，记录的是“在某个数据页上做了什么修改”，binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1

redo是循环写，而binlog是追加写。

如更新流程中：

2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

两阶段提交

redolog先prepare，再commit。

如果数据库半个月内可以回复，那么半个月内的binlog一定在，同时系统定期整库备份。

恢复到某一时间的操作：

找到最近的全量备份，从这个备份恢复到临时库。

从备份的时间开始将binlog取出，放到想要恢复的时刻。

如果不是两阶段提交：

如果写完redolog，还没写binlog就发生了crash，导致binlog没这句，最终导致期望不同。

当然如果先写binlog也有问题，写完binlog发生crash，redolog还没写，因此数据库中实际的值还没发生变化，但是binlog已经发生变化，因此相当于恢复的表多了一条事务。