分布式事务——MySQL日志介绍

Redo Log

MySQL中事务的原子性和持久性是由Redo Log实现的，它确保MySQL事务提交后，事务所涉及的所有操作要么全部执行成功，要么全部执行失败。

Redo Log也被称作重做日志，它是在InnoDB存储引擎中产生的，用来保证事务的原子性和持久性。Redo Log主要记录的是物理日志，也就是对磁盘上的数据进行的修改操作。Redo Log往往用来恢复提交后的物理数据页，不过只能恢复到最后一次提交的位置。

Redo Log通常包含两部分：一部分是内存中的日志缓冲，称作Redo Log Buffer，这部分日志比较容易丢失；另一分是存放在磁盘上的重做日志文件，称作Redo Log File，这部分日志是持久化到磁盘上的，不容易丢失。

Undo Log

MySQL中事务的一致性是由Undo Log实现的。Undo Log在MySQL事务的实现中主要起到两方面的作用：回滚事务和多版本并发事务，也就是常说的MVCC机制。

在MySQL启动事务之前，会先将要修改的数据记录存储到Undo Log中。如果数据库的事务回滚或者MySQL数据库崩溃，可以利用Undo Log对数据库中未提交的事务进行回滚操作，从而保证数据库中数据的一致性。

Undo Log会在事务开始前产生，当事务提交时，并不会立刻删除相应的Undo Log。此时，InnoDB存储引擎会将当前事务对应的Undo Log放入待删除的列表，接下来，通过一个后台线程purge thread进行删除处理。Undo Log与Redo Log不同，Undo Log记录的是逻辑日志，可以这样理解：当数据库执行一条insert语句时，Undo Log会记录一条对应的delete语句；当数据库执行一条delete语句时，Undo Log会记录一条对应的insert语句；当数据库执行一条update语句时，Undo Log会记录一条相反的update语句。

需要注意的是，因为MySQL事务执行过程中产生的Undo Log也需要进行持久化操作，所以Undo Log也会产生Redo Log。由于Undo Log的完整性和可靠性需要Redo Log来保证，因此数据库崩溃时需要先做Redo Log数据恢复，然后做Undo Log回滚。

BinLog

Redo Log是InnoDB存储引擎特有的日志，MySQL也有其自身的日志，这个日志就是BinLog，即二进制日志。

BinLog是一种记录所有MySQL数据库表结构变更以及表数据变更的二进制日志。BinLog中不会记录诸如select和show这类查询操作的日志，同时，BinLog是以事件形式记录相关变更操作的，并且包含语句执行所消耗的时间。BinLog有以下两个最重要的使用场景。

1）主从复制：在主数据库上开启BinLog，主数据库把BinLog发送至从数据库，从数据库获取BinLog后通过I/O线程将日志写到中继日志mssql数据库日志，也就是Relay Log中。然后，通过SQL线程将Relay Log中的数据同步至从数据库，从而达到主从数据库数据的一致性。

2）数据恢复：当MySQL数据库发生故障或者崩溃时，可以通过BinLog进行数据恢复。例如，可以使用mysqlbinlog等工具进行数据恢复。

MySQL事务执行流程

MySQL事务执行的过程中，主要是通过Redo Log和Undo Log实现的。MySQL事务执行流程如图所示。

MySQL在事务执行的过程中，会记录相应SQL语句的Undo Log和Redo Log，然后在内存中更新数据并形成数据脏页。接下来Redo Log会根据一定的规则触发刷盘操作，Undo Log和数据脏页则通过检查点机制刷盘。事务提交时，会将当前事务相关的所有Redo Log刷盘，只有当前事务相关的所有Redo Log刷盘成功，事务才算提交成功。

MySQL事务恢复流程

MySQL事务的执行不会总是那么顺利。如果MySQL由于某种原因崩溃或者宕机，则需要进行数据的恢复或者回滚操作。

MySQL发生崩溃或者宕机时，需要重启MySQL。MySQL重启之后，会获取日志检查点信息，随后根据日志检查点信息使用Redo Log恢复数据。如果在MySQL崩溃或者宕机时，事务未提交，则接下来使用Undo Log回滚数据。如果在MySQL崩溃或者宕机时，事务已经提交，则用RedoLog恢复数据即可。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!