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
中去了,数据不一致