前言
MySQL可以恢复到半个月内的任意一秒时的状态,这得益于它的日志系统,本文重点介绍MySQL的日志系统
提示：以下是本篇文章正文内容，下面案例可供参考
一、redo log重做日志
重做日志属于innoDB存储引擎
重做日志的操作过程类似于课堂上的临时笔记. 设想以下情景, 课堂上老师讲得太快,你来不及记笔记 , 于是先讲笔记内容简单地记在书角,在下课时再重新整理到笔记本上去.
而redo log类似于这个过程,在某一条记录需要更新的时候,MySQL先将其记录到日志系统中去 , 并更新内存.这样在用户看来更新就算完成了. 然后在适当时机再将数据存入文件系统中去.
倘若数据库发生crash, 也不会丢失之前提交的记录
二、binlog归档日志
归档日志属于server层. 用于记录语句的原始逻辑. 但是没有crash-safe能力
三、两种日志的区别
- redo log属于物理日志,记录存入的数据(做了什么修改),binlog属于逻辑日志,用于记录语句的原始逻辑
- redo log是innoDB特有的 , 而binlog则是属于server层
- redo log的空间是固定能用完的,而binlog是追加(分文件)写入的
四、两阶段提交
在做更新操作的时候,redo log的写入分为两个步骤, prepare和commit. 先做prepare,再做commit
下面先介绍更新操作的执行过程.
换个思路,假如我们不设置redo log分阶段提交
当redolog走完了全程,将日志commit掉了,binlog还未开始执行时, MySQL异常重启. 此时,binlog中并未写入该更新操作的SQL逻辑. 如果某一天MySQL需要还原了, 该更新操作的SQL逻辑就无法找回了
反之,如果先执行了binlog,此时MySQL异常重启, redolog还未将更新的数据写入日志. 那么在还原的过程中,还原回来的数据与准确数据是不符的.
因此,我们需要用到分阶段提交