Redo log 和 Bin log实现Crash safe
redo log
redo log用于保证事务的持久性，同样也是可以实现crash safe。WAL（Write-Ahead Logging）： 先写日志再写磁盘。
- 事务为什么不直接写到磁盘中？因为每次写入都会
磁盘随机IO访问，耗时，不如暂时写到redo log中，然后再找合适的时间刷到磁盘上。- 能够实现
crash safe:如果服务器宕机了，那么重启的时候会查找redo log进行数据的恢复
redo log存储的页是物理日志，采用循环写的方式，也就是我们可以写到redo log上面，我们也可以在合适的时间刷盘
上图来源于《MySQL45讲》
write pos:当前记录的位置checkpoint:当前要擦除的位置- 中间的深色区域：还可供书写的区域，如果
write pos追上了checkpoint那么就需要先停止更新，进行刷盘空闲出来一片区域再写
Crash Safe
有了
redo log， InnoDB就可以保证即使数据库发生了一场重启之前提交的记录都是会存在于redo log中，不会丢失，这个能力叫做crash safe
Crash Safe – 恢复数据
LSN:日志序列号。通过对比
LSN我们就能够知道怎么恢复数据LSN指示了
checkpoint的位置，每个数据页同样也是有LSN的，当数据库发生异常重启的时候，系统自动定位到check point，通过对比LSN就能判断是否是需要恢复 & 怎么恢复
bin log
bin log是server层的日志，用于数据误删后的恢复以及主从复制
两日志文件对比：
redo log是InnoDB引擎特有的，bin log是所有引擎都可以实现redo log是物理日志，bin log是逻辑日志redo log是循环写的，bin log是追加写的
两阶段提交
为什么需要两阶段提交？
- 先写
redo log再写bin log,如果写完redo log就宕机了，重启之后用redo log恢复的数据就比bin log多，造成数据不一致- 先写
bin log再写redo log,写完bin log就宕机了，重启后redo log这个事务无效，但是写到了bin log中去了，数据不一致
