MySQL InnoDB存储引擎undo redo解析

本文介绍MySQL数据库InnoDB存储引擎重做日志漫游





00 – Undo Log

Undo Log 为了实现事务原子，在MySQL数据库InnoDB存储引擎，还使用Undo Log(简称：MVCC)。

- 事务的原子性(Atomicity)

  事务中的所有操作，要么所有完毕，要么不做不论什么操作，不能仅仅做部分操作。假设在运行的过程中发生

  了错误。要回滚(Rollback)到事务開始前的状态，就像这个事务从来没有运行过。

- 原理

  Undo Log的原理非常easy。为了满足事务的原子性，在操作不论什么数据之前。首先将数据备份到一个地方

  （这个存储数据备份的地方称为Undo Log）。然后进行数据的改动。假设出现了错误或者用户运行了

  ROLLBACK语句。系统能够利用Undo Log中的备份将数据恢复到事务開始之前的状态。





除了能够保证事务的原子性。Undo Log也能够用来辅助完毕事务的持久化。





- 事务的持久性(Durability)

  事务一旦完毕。该事务对数据库所做的全部改动都会持久的保存到数据库中。为了保证持久性，数据库

  系统会将改动后的数据全然的记录到持久的存储上。

- 用Undo Log实现原子性和持久化的事务的简化过程

  如果有A、B两个数据，值分别为1,2。

  A.事务開始.

  B.记录A=1到undo log.

  C.改动A=3.

  D.记录B=2到undo log.

  E.改动B=4.

  F.将undo log写到磁盘。

  G.将数据写到磁盘。

  H.事务提交

  这里有一个隐含的前提条件：‘数据都是先读到内存中，然后改动内存中的数据。最后将数据写回磁盘’。





  之所以能同一时候保证原子性和持久化，是由于下面特点：

  A. 更新数据前记录Undo log。

  B. 为了保证持久性。必须将数据在事务提交前写到磁盘。仅仅要事务成功提交，数据必定已经持久化。

  C. Undo log必须先于数据持久化到磁盘。假设在G,H之间系统崩溃，undo log是完整的，

     能够用来回滚事务。

  D. 假设在A-F之间系统崩溃,由于数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务開始前的状态。

缺陷：每一个事务提交前将数据和Undo Log写入磁盘。这样会导致大量的磁盘IO。因此性能非常低。





假设可以将数据缓存一段时间，就能降低IO提高性能。可是这样就会丧失事务的持久性。因此引入了另外一

种机制来实现持久化。即Redo Log.





01 – Redo Log





- 原理

  和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，仅仅要将Redo Log持久化就可以，

  不须要将数据持久化。当系统崩溃时。尽管数据没有持久化，可是Redo Log已经持久化。系统能够依据

  Redo Log的内容。将全部数据恢复到最新的状态。

- Undo + Redo事务的简化过程

  如果有A、B两个数据，值分别为1,2.

  A.事务開始.

  B.记录A=1到undo log.

  C.改动A=3.

  D.记录A=3到redo log.

  E.记录B=2到undo log.

  F.改动B=4.

  G.记录B=4到redo log.

  H.将redo log写入磁盘。

  I.事务提交





- Undo + Redo事务的特点

  A. 为了保证持久性，必须在事务提交前将Redo Log持久化。

  B. 数据不须要在事务提交前写入磁盘，而是缓存在内存中。

  C. Redo Log 保证事务的持久性。

  D. Undo Log 保证事务的原子性。

  E. 有一个隐含的特点，数据必需要晚于redo log写入持久存储。





- IO性能

  Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，降低了写数据的IO.

  可是却引入了新的IO，即写Redo Log的IO。

假设Redo Log的IO性能不好。就不能起到提高性能的目的。

为了保证Redo Log可以有比較好的IO性能，InnoDB 的 Redo Log的设计有下面几个特点：





  A. 尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间全然分配。

以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。

B. 批量写入日志。日志并非直接写入文件。而是先写入redo log buffer.当须要将日志刷新到磁盘时

     (如事务提交),将很多日志一起写入磁盘.

  C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的运行顺序。依次交替的记录在一起。

     以降低日志占用的空间。比如,Redo Log中的记录内容可能是这种：

     记录1: <trx1, insert …>

     记录2: <trx2, update …>

     记录3: <trx1, delete …>

     记录4: <trx3, update …>

     记录5: <trx2, insert …>

  D. 由于C的原因,当一个事务将Redo Log写入磁盘时。也会将其它未提交的事务的日志写入磁盘。

  E. Redo Log上仅仅进行顺序追加的操作，当一个事务须要回滚时，它的Redo Log记录也不会从

     Redo Log中删除掉。

02 – 恢复(Recovery)





- 恢复策略

  前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的

  的处理.有2中不同的恢复策略：





  A. 进行恢复时，仅仅重做已经提交了的事务。

  B. 进行恢复时。重做全部事务包含未提交的事务和回滚了的事务。然后通过Undo Log回滚那些

     未提交的事务。





- InnoDB存储引擎的恢复机制

  MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：





  A. 在重做Redo Log时。并不关心事务性。

恢复时，没有BEGIN。也没有COMMIT,ROLLBACK的行为。

也不关心每一个日志是哪个事务的。

虽然事务ID等事务相关的内容会记入Redo Log，这些内容仅仅是被当作

     要操作的数据的一部分。

B. 使用B策略就必需要将Undo Log持久化，并且必需要在写Redo Log之前将相应的Undo Log写入磁盘。

     Undo和Redo Log的这样的关联。使得持久化变得复杂起来。

为了减少复杂度，InnoDB将Undo Log看作

     数据，因此记录Undo Log的操作也会记录到redo log中。

这样undo log就能够象数据一样缓存起来，

     而不用在redo log之前写入磁盘了。

包括Undo Log操作的Redo Log，看起来是这种：

     记录1: <trx1, Undo log insert <undo_insert …>>

     记录2: <trx1, insert …>

     记录3: <trx2, Undo log insert <undo_update …>>

     记录4: <trx2, update …>

     记录5: <trx3, Undo log insert <undo_delete …>>

     记录6: <trx3, delete …>

  C. 到这里，另一个问题没有弄清楚。既然Redo没有事务性，那岂不是会又一次运行被回滚了的事务？

     确实是这样。同一时候Innodb也会将事务回滚时的操作也记录到redo log中。

回滚操作本质上也是

     对数据进行改动，因此回滚时对数据的操作也会记录到Redo Log中。

一个回滚了的事务的Redo Log。看起来是这种：

     记录1: <trx1, Undo log insert <undo_insert …>>

     记录2: <trx1, insert A…>

     记录3: <trx1, Undo log insert <undo_update …>>

     记录4: <trx1, update B…>

     记录5: <trx1, Undo log insert <undo_delete …>>

     记录6: <trx1, delete C…>

     记录7: <trx1, insert C>

     记录8: <trx1, update B to old value>

     记录9: <trx1, delete A>

     一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.





- InnoDB存储引擎相关的功能

  Redo: recv_recovery_from_checkpoint_start()

  Undo: recv_recovery_rollback_active()

  Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()