《分布式恢复》PPT课件.ppt

《《分布式恢复》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《分布式恢复》PPT课件.ppt（40页珍藏版）》请在三一办公上搜索。

1、第七章 分布式恢复,基本概念集中式数据库的故障恢复方法分布式事务的恢复,Reliability Problem:How to maintain(1)atomicity(2)durability properties of transactionsSpecific reliability protocols related include:(1)commit protocols,and(2)recovery protocols.,7.1 基本概念,1、可靠性和可用性分布式数据库系统本身的体系结构可提高系统的可靠性和可用性；片段数据的重复存储和系统采用的恢复措施等都可提高系统的可靠性和可用性。可靠

2、性和可用性的具体描述如下：可靠性（Reliability）体现下面几点：一个系统符合其行为规范的量度；系统在给定时间间隔内不出故障的概率；用来描述不可修复的或要求连续操作的系统的重要指标。可用性（Availability）体现下面几点：系统可满足其规范的时间百分率；系统在给定时间t上正常运行的概率；,7.1 基本概念,2 故障模型恢复是数据库系统在系统出现故障的情况下采取的补救措施，使系统恢复到出错前的正确状态，系统恢复正确后，可继续运行，不会因系统故障造成数据库损坏和数据丢失。归纳系统可能出现的故障，可分为Fault(故障)、Error(错误)和Failure(失效)三种故障形式。故障模型（

3、见图7.1）。,7.1 基本概念,说明：刺激：来自外界的影响；响应：来自于系统的信息；内部状态：系统内部的状态；外部状态：系统所处环境内的系统的外部状态；,7.1 基本概念,下面介绍三种故障形式为：Fault(故障)：指系统单元所处的内部状态发生的错误或系统内设计错误。Error(错误)：指出现了不正确的状态。Failure(失效)：指系统的外部状态中的错误。通常，由于Fault(故障)引发Error(错误)；由Error(错误)导致执行失效，即Failure(失效)。如下图所示：,Causes,Results in,3、故障类型系统故障常分为两大类：硬故障和软故障。硬故障通常是永久的，不能自

4、动修复。如：系统硬件设备（永久存储设备）的故障导致的系统数据丢失故障。硬故障导致的failure(失效)，称为硬失效。这种故障对数据库系统是致命的，应尽力避免。软故障通常是临时性或间歇性的。如：由于故障使数据库数据丢失或出错，使事务不能正确提交；系统死锁或算术溢出、被零除等造成的系统错误等。这些故障大多是临时性的，多是由于系统不稳定造成的，较容易恢复。如：系统可通过恢复机制进行恢复或重新启动事务恢复。通常这些软故障导致的failure(失效)，称为软失效。系统的failure90%是软失效。图7.2说明了故障的分类。,7.1 基本概念,7.1 基本概念,(Mean Time between F

5、ailures)(Mean Time to Repair)(Mean Time to Detect),5、分布库系统中的故障分布式数据库系统主要由结点及结点间的通讯链路组成。因此，在分布式数据库系统中，除了可能出现集中式数据库系统可能出现的故障外，还可能出现分布式数据库系统特有的故障，如：通信链路故障等。根据分布式数据库特点，其故障可归纳如下类型：(1)事务故障事务故障主要由系统单个事务或系统死锁引起的，使事务被废弃。如：算术溢出、被零除、超时、申请资源过多等。通常一个系统约有3%的事务被异常废弃。这一类故障不会导致存储介质上的数据被破坏，是一种影响性较小的可排除性的局部故障，由系统恢复机制自

6、动恢复或重新启动事务来恢复。,7.1 基本概念,（2）系统（场地）故障系统（场地）故障主要由处理器、主存、电源、系统过载、系统崩溃等等造成的，往往涉及多个或全部事务，造成系统局部或系统全部出现故障。这类故障使主存的内容丢失，但外存的内容是安全的。（3）介质故障介质故障是由于外存设备故障引起的，如：磁头坏、驱动卡坏、扇区坏等。这类故障对数据库系统是致命的，导致外存数据部分或全部丢失。（4）通讯故障通讯故障主要指报文丢失和网络分割。报文丢失是指在传送过程中由于报文丢失而导致的数据错误。网络分割是指系统的一个场地与另一场地失去联系，使两场地间无法通讯。,7.1 基本概念,集中式数据库的故障分为硬故障

7、和软故障两类。故障主要体现在是事务永久性的，还是间歇性的；是导致了外存数据错误，还是使内存数据发生错误。针对可能产生的不同故障，应采用相应的故障恢复方法。介绍故障恢复之前，了解一下数据库中数据的更新方法、缓冲区中数据更新方法等内容。1、局部恢复系统的体系结构尽管系统可能出现有各式各样的故障，但故障恢复的系统体系结构是一致的。,7.2 集中式数据库的故障恢复方法,2、数据库更新策略 数据库数据的更新通常采用两种更新方法，即原地更新和异地更新。原地更新是指数据库的更新操作直接修改数据库缓冲区中的旧值。异地更新是指数据库的更新操作将数据项新值存在于旧值不同的位置上。如：采用影子页面（shadowin

8、g page）或采用差分文件方式存储。影子页面是指当更新数据时，不改变旧存储页面，而是建一影子页面，将新值存于新建的影子页面上。而旧页面用于故障恢复。差分文件（F）由只读部分（FR）加上插入部分（DF+）和删除部分（DF-）组成，即F=（FR（只读）DF（插入）+）-DF-（删除）。更新等价于删除旧值，插入新值完成。,7.2 集中式数据库的故障恢复方法,3、缓冲区更新策略缓冲区更新策略由固定/非固定（fix/non_fix）和刷新/非刷新(flash/no_flush)组合，共组成4种缓冲区更新策略。即fix/flush、fix/no_flush、non_fix/flush和non_fix/n

9、o_flush。固定/非固定（fix/non_fix）是指缓冲区管理器是否等到局部恢复管理器（LRM）发的命令后，才将缓冲区中修改的内容写到外存数据库。刷新/非刷新(flush/no_flush)是指在事务执行结束后，局部恢复管理器（LRM）是否强制缓冲区管理器将其中已修改的数据写回外存数据库。,7.2 集中式数据库的故障恢复方法,4、不同执行策略的恢复要求(1)fix/flush方式-废弃事务时没有将修改的数据写入外存。因为在事务结束之前，所修改的数据页面已被固定，直到事务提交时，才被释放。同时需释放所有被固定的页面。被提交的事务的更新数据都刷新到外存数据库。其处理过程：LRM向缓冲区管理器

10、发flush命令，将更新数据刷新到外存；LRM向缓冲区管理器发unfix命令释放所有被固定的页面；LRM向日志文件中写事务结束记录。该种执行策略对废弃事务不需做任何恢复操作。,7.2 集中式数据库的故障恢复方法,4、不同执行策略的恢复要求(2)fix/noflush方式-废弃事务没有将修改的数据写入外存。被提交的事务的更新数据可能没有被刷新到外存数据库。因为其处理过程为：LRM向日志文件中写事务结束记录；LRM向缓冲区管理器发unfix命令释放所有被固定的页面。该种执行策略的事务恢复需执行部分重做（redo），不需执行全局反做（undo）处理。,7.2 集中式数据库的故障恢复方法,(3)no_

11、fix/flush方式-废弃事务的部分结果可能已被写入外存。被提交的事务的更新数据都刷新到外存数据库，处理过程为：LRM向缓冲区管理器发flush命令，将更新数据刷新到外存；LRM向日志文件中写事务结束记录。该种执行策略的事务恢复操作应需对事务全部进行反做（undo）处理，不需要重做(redo)。,7.2 集中式数据库的故障恢复方法,(4)no_fix/no_flush方式 废弃事务的部分修改的数据可能已写入外存。被提交的事务的更新数据可能没有被刷新到外存数据库。因为其处理过程为:LRM向日志文件中写事务结束记录。该种执行策略的事务恢复操作过程为：LRM对日志中只有“begin”，没有“end

12、”的事务全部进行反做（undo）处理；LRM对日志中既有“begin”，又有“end”的事务部分进行重做（redo）处理；,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,在日志中，系统的运行情况以运行记录的形式存放，日志中具体存放信息如下：（1）数据日志记录内容为：事务标识符；操作类型；操作的数据项；数据项的旧值；数据项的新值；（2）命令日志记录内容为：事务标识符；命令（如：begin,abort,commit）；,7.2 集中式数据库的故障恢复方法,（3）检查点日志记录检查点是在日志中周期设定的操作标志，目的是减少系统故障后的恢复的工作量。在检查点上，需要完成的操作

13、：将日志缓冲区中的内容写入外存中的日志；在外存日志中登记一个检查点记录；将数据库缓冲区的内容写入外存数据库；把外存日志中检查点的地址写入重启动文件。使检查点以前的工作持久化。当系统出现故障时，只对最近的检查点以后的操作进行恢复处理。,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,6、基本的恢复操作系统故障发生时，造成数据库不一致状态的原因为：一些未完成事务对数据库的更新已写入外存数据库；一些已提交事务对数据库的更新还没写入外存数据库。因此，基本的恢复操作分两类，即反做（undo）和重做（redo）。反做（undo）也称撤消。（1）反做（undo）反做（undo）是将一

14、个数据项的值恢复到其修改之前的值，即取消一个事务所完成的操作结果（见图7.2所示）。当一个事务尚没提交时，如果缓冲区管理器允许该事务修改过的数据写到外存数据库，一旦此事务出现故障需废弃时，就需对被这个事务修改过的数据项进行反做（undo），即恢复到其前像。反做（undo）保持数据库的原子性。,7.2 集中式数据库的故障恢复方法,（2）重做（redo）重做（redo）是将一个数据项的值恢复到其修改后的值，即恢复一个事务的操作结果（见图7.2所示）。当一个事务提交时，如果缓冲区管理器允许该事务修改过的数据不立刻写到外存数据库，一旦此事务出现故障，需对被这个事务修改过的数据项进行重做（redo），即

15、恢复到其后像。重做（redo）保持数据库的永久性。,7.2 集中式数据库的故障恢复方法,有数据项x,x值为10。设有一事务T，执行操作x=20。若执行过程中出现错误，则：undo（T）：x=10;redo（T）：x=20;（3）重做（redo）和反做（undo）基本特性如果在进行反做（undo）处理时又发生了故障，则要重新进行反做（undo）处理，所以对一事务的一次或多次反做（undo）处理应是等价的，该特性称为反做（undo）的幂等率。反做（undo）的幂等率表示为：undo（undo（T）=undo（T）同理，重做（redo）也有幂等率特性。重做（redo）的幂等率表示为：redo（red

16、o（T）=redo（T）重做（redo）和反做（undo）幂等率说明，对一个事务T执行任意多次redo/undo操作，其效果应与执行一次redo/undo操作的结果相同。,7.2 集中式数据库的故障恢复方法,7、先写日志协议（WAL（Write_ahead logging）系统的故障恢复是以日志文件为基础完成的，因此，要求事务在执行过程中满足先写日志协议（WAL）。当系统发生故障时，可有效地采用重做（redo）和反做（undo）两个基本恢复操作进行恢复。先写日志协议（WAL）含义：（1）在外存数据库被更新之前，应将日志文件中的反做信息写入外存文件；（2）事务提交之前，日志文件中的有关重做信息应

17、在外存数据库更新之前写入外存文件。,7.2 集中式数据库的故障恢复方法,8、对内存信息丢失故障的恢复处理方法假设缓冲区执行策略为no_fix/no_flush方式。no_fix/no_flush方式故障表现为：废弃事务的部分修改的数据可能已写入外存；被提交的事务的更新数据可能没有被刷新到外存数据库。因此，其恢复操作过程为：对日志中只有“begin”，没有“end”的事务全部进行反做（undo）处理；对日志中既有“begin”，又有“end”的事务部分进行重做（redo）处理。（1）故障分析事务的执行过程用树型结构图（见图7.6）来说明。事务执行过程为：事务或执行结束或中断即废弃。若废弃，需反做

18、（undo）处理，结束事务；若执行结束，进行提交或发生故障废弃。若废弃，反做（undo）处理，结束事务；若正确提交，将结果写入外存或发生故障部分结果未写入外存。若结果写入外存结束，事务正确执行结束，数据永久化；若部分结果未写入外存，需重做（redo）处理，结束事务。,7.2 集中式数据库的故障恢复方法,（2）故障恢复当事务执行中出现故障时，需对事务进行重做（redo）和反做（undo）恢复处理，具体恢复过程为：恢复子系统首先从重启动文件中取得最近的检查点的地址，然后建立两个表：重做表和反做表。初始化两表，重做表初态为空；反做表初态为检查点上活动事务。活动事务指检查点上还没有结束的事务。确定反做

19、事务表（undo表）：在日志中从检查点向前搜索，直到日志结尾。找出只有B记录没有C记录的事务，即在系统故障时未结束的事务，写入反做事务表。确定重做事务表（redo表）：从检查点向前搜索,找出既有B记录也有C记录的事务（将该事务从undo表删除），直到日志结尾,即在系统故障时已经提交但部分结果未写入外存的事务，写入重做事务表。反做（undo）反做事务表中的所有事务。根据日志反向进行撤消操作，直到相应事务的B(begin transaction).重做（redo）重做事务表中的所有事务。根据日志从检查点正向进行重做操作，直到相应事务的C（commit transaction）。,7.2 集中式数据

20、库的故障恢复方法,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,1、通信故障通信故障有两种：报文丢失和网络分割。若存在两个结点A和B，报文丢失指A最大延迟内没有收到B发来的报文。网络分割指网络被断开或存在两个以上不相联接的子网。如果系统不存在通信故障，则应表现如下情况：（1）收到的报文内容及报文顺序均正确；（2）无超时错误发生。无超时错误指在发送报文后，在规定的延迟时间内应收到返回的应答信息。另外，除网络分割可能造成报文丢失外，场地故障也可造成报文丢失。根据分布式数据库系统的特征，分布事务的执行是分解为若干个不同场地上的子事务的执行。因此，分布事务提交的先决条件是分布

21、事务的所有子事务必须全部提交，否则事务全部废弃。为使分布式事务正确提交，通常采用两段提交协议（2PC）即基本的两阶段提交协议。,7.3 分布式事务的恢复,1、具有恢复功能的两段提交协议（2PC）（1）两段提交协议（2PC）两段提交协议（2PC）的思想概括地说是事务提交分两个阶段：决定阶段和执行阶段。决定阶段是作出提交/废弃的决定；执行阶段实现决定阶段的决定。具体可用下面流程图描述（见图7.8）。为说明两段提交协议，先介绍几个扩充的日志记录：Prepare记录：内容为事务标识（tid），Prepare代码；Ready记录：内容为事务标识（tid），Ready代码；Complete记录：内容为事务

22、标识（tid），Complete代码。Prepare记录、Ready记录和Complete记录简称P记录、R记录和C记录。,7.3 分布式事务的恢复,7.3 分布式事务的恢复,1、场地故障的恢复处理两段提交协议（2PC）具有恢复场地故障和通信故障的特性，下面以两段提交协议（2PC）实现的概要图(图7.9)，对场地故障的恢复进行描述。,7.3 分布式事务的恢复,场地故障分析：（1）故障：在参与者场地，参与者在写R/A记录之前出错。此时，协调者发完Prepare命令后在规定时间内收不到应答信息。恢复：协调者发现超时，做Abort处理，即缺省认为收到Abort应答。,7.3 分布式事务的恢复,场地故

23、障分析：（2）故障：在参与者场地，参与者在写R/A记录之后，写C/A记录之前出错。恢复：故障场地重新启动，向协调者或其它场地重新请求命令（C/A）。,7.3 分布式事务的恢复,场地故障分析：（3）故障：在协调者场地，协调者在写P记录之后，写C/A记录之前出错。恢复：协调者重新启动后，重新执行2PC协议。,7.3 分布式事务的恢复,场地故障分析：（4）故障：在协调者场地，协调者在写C/A记录之后，写Complete记录之前出错。恢复：没收到命令的参与者保持等待，协调者重新启动后，给所有参与者重发其决定的命令。,7.3 分布式事务的恢复,2、通信故障的恢复通信故障分报文丢失和网络分割两种。通信故障

24、的直观表现是造成传输信息的丢失。丢失的信息可分为命令信息、响应信息及数据库信息。当命令或响应信息丢失时，直接影响事务的实现。（1）报文丢失故障的恢复 根据丢失的报文信息类型（见图7.10），有下面几种情况：丢失P命令报文；丢失R/A响应报文；丢失C/A命令报文；丢失ACK响应报文；,7.3 分布式事务的恢复,根据丢失的报文信息类型（见图7.10），有下面几种情况丢失P命令报文：协调者保持等待，发现超时，作“Abort”处理，即缺省收到Abort废弃响应。丢失R/A响应报文：同“丢失P命令报文”处理，既协调者保持等待，发现超时，作“Abort”处理。丢失C/A命令报文：参与者利用超时机制，要求协调者重发C/A命令。丢失ACK响应报文：协调者利用超时机制，向参与者重发C/A命令，要求参与者给予应答。,7.3 分布式事务的恢复,（2）网络分割故障的恢复处理在网络分割故障中，采用的故障恢复思想是：先将网络中所有场地结点分为两大区，包含协调者的分区和不包含协调者的分区。包含协调者的分区称协调者群；不包含协调者的分区称参与者群。之后，分两种情况进行恢复处理：在协调者群中，若认为参与者群出故障，则故障恢复同场地故障的（1）和（2）。在参与者群中，若认为协调者群出故障，则故障恢复同场地故障的（3）和（4）。,7.3 分布式事务的恢复,