Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > mysql事务重做日志与回滚日志

mysql中的事务重做日志(redo log)与回滚日志(undo log)

作者:小洪帽i

这篇文章主要介绍了mysql中的事务重做日志(redo log)与回滚日志(undo log),具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教

事务重做日志(redo log)与回滚日志(undo log)

查看事务日志:

show engine innodb status;
show engine innodb status\G;

查看日志文件设置状态:

show variables like 'innodb_%';

注意:在 MySQL 中对于数据来说,最为重要的是日志文件

redo log => ib_logfile0…
undo log => ibdata

重做日志

持久化

事务被提交,数据一定会被写入到数据库中并持久存储起来,通常来说当事务已经被提交之后,就无法再次回滚了。

重做日志实现持久化

与原子性一样,事务的持久性也是通过日志来实现的,MySQL 使用重做日志( redo log )实现事务的持久性,重做日志由两部分组成,一是内存中的重做日志缓冲区,因为重做日志缓冲区在内存中,所以它是易失的;另一个就是在磁盘上的重做日志文件,它是持久的。

当我们在一个事务中尝试对数据进行写时,它会先将数据从磁盘读入内存,并更新内存中缓存的数据,然后生成一条重做日志并写入重做日志缓存,当事务真正提交时,MySQL 会将重做日志缓存中的内容刷新到重做日志文件,再将内存中的数据更新到磁盘上,图中的第4、5步就是在事务提交时执行的。

重做日志执行

在MySQL中事务执行 commit 提交了之后,但是服务器宕机了,数据还没有写入磁盘,在MySQL重启服务之后会重新执行这个重做日志写入数据。

回滚日志

原子性

通俗的解释就是:一条绳子上的蚂蚱。

专业性的解释是:事务一系列的操作,要么全部执行,要么都不执行。

回滚日志实现原子性

想要保证事务的原子性,就需要在异常发生时,对已经执行的操作进行回滚,而在 MySQL 中,恢复机制是通过回滚日志( undo log )实现的,所有事务进行的修改都会先记录到这个回滚日志中,然后再对数据库中的对应行进行写入。

注意:系统发生崩溃、数据库进程直接被杀死后,当用户再次启动数据库进程时,还能够立刻通过查询回滚日志将之前未完成的事务进行回滚,这也就需要回滚日志必须先于数据持久化到磁盘上,是我们需要先写日志后写数据库的主要原因。

在日志文件中:在事务中使用的每一条 insert into 都对应了一条 delete ,每一条 update 也对应一条相反的 update 语句。

回滚日志执行

测试:在事务提交前停止mysql服务

然后我们停止MySQL服务:

停止成功;然后再开启 MySQL 服务:

启动成功,然后查询一下数据:

没有查询到新增的数据;数据已经丢失了,需要执行了commit之后数据才不会丢失。

重做日志与回滚日志总结

到现在为止我们了解了 MySQL 中的两种日志,回滚日志( undo log )和重做日志( redo log );在数据库系统中,事务的原子性和持久性是由事务日志( transaction log )保证的,在实现时也就是上面提到的两种日志;欠着用于对事务的影响进行撤销,后者在错误处理时对已经提交的事务进行重做,它们能保证两点:

发生错误或者需要回滚的事务能够成功回滚(原子性)。在事务提交后,数据没来得及写入磁盘就宕机时,在下次重新启动后能够成功恢复数据(持久性)。

在数据库中,这两种日志经常都是一起工作的,我们可以将他们整体看作一条事务日志,其中包含了事务的ID、修改的行元素以及修改前后的值。

总结 

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文