MySQL 里有两个日志,即:重做日志(redo log)和归档日志(binlog)。
其中,binlog 可以给备库使用,也可以保存起来用于恢复数据库历史数据。它是实现在 server 层的,所有引擎可以共用。redo log 是 InnoDB 特有的日志,用来支持 crash-safe 能力。
有了 redo log , InnoDB 就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为 crash-safe 。
你一定听过 MySQL 事务的两阶段提交,指的就是在事务提交的时候,分成 prepare (准备)和 commit(提交) 两个阶段。
如图所示为一个事务的执行流程,你在最后三步可以看到,redo log 先 prepare 完成,再写 binlog,最后才进入 redo log commit 阶段。
这里,我要先和你解释一个误会式的问题:这个图不就是一个 update 语句的执行流程吗,怎么还会调用 commit 语句?
通常情况下,你会产生这个疑问的原因,在于把两个“commit”的概念混淆了:
问题中的“commit 语句”,是指 MySQL 语法中,用于提交一个事务的命令。一般跟 begin/start transaction 配对使用。
而我们图中用到的这个“commit 步骤”,指的是事务提交过程中的一个小步骤,也是最后一步。当这个步骤执行完成后,这个事务就提交完成了。
“commit 语句”执行的时候,会包含“commit 步骤”。
而我们这个例子里面,没有显式地开启事务,因此这个 update 语句自己就是一个事务,在执行完成后提交事务时,就会用到这个“commit 步骤”
接下来,我们就一起分析一下在两阶段提交的不同时刻,MySQL 异常重启会出现什么现象。
如果在图中时刻 A 的地方,也就是写入 redo log 处于 prepare 阶段之后、写 binlog 之前,发生了崩溃(crash),由于此时 binlog 还没写,redo log 也还没提交,所以崩溃恢复的时候,这个事务会回滚。这时候,binlog 还没写,所以也不会传到备库