MySQL,MariaDB:Undo | Redo [转]

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

00 – Undo Log
Undo Log 是为着贯彻工作的原子性,在MySQL数据库InnoDB存储引擎中,还用Undo
Log来落到实处多版本出现控制(简称:MVCC)。

– 事务的原子性(Atomicity)
  事务中的所有操作,要么全体成功,要么不做任何操作,不可能只做一些操作。倘若在执行的进度中发生
  了错误,要回滚(Rollback)到工作开始前的情况,似乎这么些业务平素没有执行过。

– 原理
  Undo
Log的法则很粗略,为了满意工作的原子性,在操作任何数据以前,首先将数据备份到一个地点
  (那个蕴藏数据备份的地点叫作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()

 

网站地图xml地图