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

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

查看事务日志：

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

查看日志文件设置状态：

show variables like 'innodb_%';

• innodb_log_files_in_group:DB 中设置几组事务日志，默认是2；
• innodb_log_group_home_dir 事务日志存放目录，不设置；
• ib_logfile0… 存放在数据文件目录下 InnoDB 存储引擎可将所有数据存放于 ibdata* 的共享表空间，也可将每张表存放于独立的 .ibd 文件的独立表空间；

注意：在 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 语句。

回滚日志执行

• 1.手动执行回滚命令时会执行。
• 2.如果程序在事务执行之后，提交命令执行之前出现了异常，在下次 MySQL 服务重启的时候会执行。

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

然后我们停止MySQL服务：

停止成功；然后再开启 MySQL 服务：

启动成功，然后查询一下数据：

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

重做日志与回滚日志总结

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

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

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

总结 

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

最新评论