1、第七章 分布式恢复,基本概念 集中式数据库的故障恢复方法 分布式事务的恢复,Reliability Problem: How to maintain(1) atomicity (2) durabilityproperties of transactions Specific reliability protocols related include:(1) commit protocols, and (2) recovery protocols.,7.1 基本概念,1、 可靠性和可用性 分布式数据库系统本身的体系结构可提高系统的可靠性和可用性；片段数据的重复存储和系统采用的恢复措施等都可提高系
2、统的可靠性和可用性。可靠性和可用性的具体描述如下：可靠性（Reliability）体现下面几点： 一个系统符合其行为规范的量度； 系统在给定时间间隔内不出故障的概率； 用来描述不可修复的或要求连续操作的系统的重要指标。可用性（Availability）体现下面几点： 系统可满足其规范的时间百分率； 系统在给定时间t上正常运行的概率；,7.1 基本概念,2 故障模型 恢复是数据库系统在系统出现故障的情况下采取的补救措施，使系统恢复到出错前的正确状态，系统恢复正确后，可继续运行，不会因系统故障造成数据库损坏和数据丢失。归纳系统可能出现的故障，可分为Fault(故障)、Error(错误)和Failu
3、re(失效)三种故障形式。故障模型（见图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 基本概
5、念,(Mean Time between Failures) (Mean Time to Repair) (Mean Time to Detect),5、分布库系统中的故障 分布式数据库系统主要由结点及结点间的通讯链路组成。因此，在分布式数据库系统中，除了可能出现集中式数据库系统可能出现的故障外，还可能出现分布式数据库系统特有的故障，如：通信链路故障等。根据分布式数据库特点，其故障可归纳如下类型： (1) 事务故障 事务故障主要由系统单个事务或系统死锁引起的，使事务被废弃。如：算术溢出、被零除、超时、申请资源过多等。通常一个系统约有3%的事务被异常废弃。这一类故障不会导致存储介质上的数据被破坏
6、，是一种影响性较小的可排除性的局部故障，由系统恢复机制自动恢复或重新启动事务来恢复。,7.1 基本概念,（2）系统（场地）故障 系统（场地）故障主要由处理器、主存、电源、系统过载、系统崩溃等等造成的，往往涉及多个或全部事务，造成系统局部或系统全部出现故障。这类故障使主存的内容丢失，但外存的内容是安全的。 （3）介质故障 介质故障是由于外存设备故障引起的，如：磁头坏、驱动卡坏、扇区坏等。这类故障对数据库系统是致命的，导致外存数据部分或全部丢失。 （4）通讯故障 通讯故障主要指报文丢失和网络分割。报文丢失是指在传送过程中由于报文丢失而导致的数据错误。网络分割是指系统的一个场地与另一场地失去联系，使
7、两场地间无法通讯。,7.1 基本概念,集中式数据库的故障分为硬故障和软故障两类。故障主要体现在是事务永久性的，还是间歇性的；是导致了外存数据错误，还是使内存数据发生错误。针对可能产生的不同故障，应采用相应的故障恢复方法。介绍故障恢复之前，了解一下数据库中数据的更新方法、缓冲区中数据更新方法等内容。 1、 局部恢复系统的体系结构 尽管系统可能出现有各式各样的故障，但故障恢复的系统体系结构是一致的。,7.2 集中式数据库的故障恢复方法,2、数据库更新策略数据库数据的更新通常采用两种更新方法，即原地更新和异地更新。原地更新是指数据库的更新操作直接修改数据库缓冲区中的旧值。异地更新是指数据库的更新操作
8、将数据项新值存在于旧值不同的位置上。如：采用影子页面（shadowing page）或采用差分文件方式存储。 影子页面是指当更新数据时，不改变旧存储页面，而是建一影子页面，将新值存于新建的影子页面上。而旧页面用于故障恢复。 差分文件（F）由只读部分（FR）加上插入部分（DF+）和删除部分（DF-）组成， 即F =（FR（只读）DF（插入）+）-DF-（删除）。更新等价于删除旧值，插入新值完成。,7.2 集中式数据库的故障恢复方法,3、缓冲区更新策略 缓冲区更新策略由固定/非固定（fix/non_fix）和刷新/非刷新(flash/no_flush)组合，共组成4种缓冲区更新策略。即fix/ f
9、lush、fix/ no_flush、non_fix/ flush和non_fix/ no_flush。 固定/非固定（fix/non_fix）是指缓冲区管理器是否等到局部恢复管理器（LRM）发的命令后，才将缓冲区中修改的内容写到外存数据库。 刷新/非刷新(flush/no_flush)是指在事务执行结束后，局部恢复管理器（LRM）是否强制缓冲区管理器将其中已修改的数据写回外存数据库。,7.2 集中式数据库的故障恢复方法,4、不同执行策略的恢复要求 (1) fix/ flush方式- 废弃事务时没有将修改的数据写入外存。因为在事务结束之前，所修改的数据页面已被固定，直到事务提交时，才被释放。同
10、时需释放所有被固定的页面。 被提交的事务的更新数据都刷新到外存数据库。其处理过程： LRM向缓冲区管理器发flush命令，将更新数据刷新到外存； LRM向缓冲区管理器发unfix命令释放所有被固定的页面； LRM向日志文件中写事务结束记录。 该种执行策略对废弃事务不需做任何恢复操作。,7.2 集中式数据库的故障恢复方法,4、不同执行策略的恢复要求 (2) fix/ noflush方式- 废弃事务没有将修改的数据写入外存。被提交的事务的更新数据可能没有被刷新到外存数据库。因为其处理过程为： LRM向日志文件中写事务结束记录； LRM向缓冲区管理器发unfix命令释放所有被固定的页面。该种执行策略
11、的事务恢复需执行部分重做（redo），不需执行全局反做（undo）处理。,7.2 集中式数据库的故障恢复方法,(3) no_fix/ flush方式- 废弃事务的部分结果可能已被写入外存。 被提交的事务的更新数据都刷新到外存数据库，处理过程为： LRM向缓冲区管理器发flush命令，将更新数据刷新到外存； LRM向日志文件中写事务结束记录。 该种执行策略的事务恢复操作应需对事务全部进行反做（undo）处理，不需要重做(redo)。,7.2 集中式数据库的故障恢复方法,(4) no_fix/ no_flush方式 废弃事务的部分修改的数据可能已写入外存。 被提交的事务的更新数据可能没有被刷新到外
12、存数据库。因为其处理过程为: LRM向日志文件中写事务结束记录。 该种执行策略的事务恢复操作过程为： LRM对日志中只有“begin”，没有“end”的事务全部进行反做（undo）处理； LRM对日志中既有“begin”，又有“end”的事务部分进行重做（redo）处理；,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,在日志中，系统的运行情况以运行记录的形式存放，日志中具体存放信息如下： （1） 数据日志记录内容为： 事务标识符； 操作类型； 操作的数据项； 数据项的旧值； 数据项的新值； （2） 命令日志记录内容为： 事务标识符； 命令（如：begin,abort,
13、commit）；,7.2 集中式数据库的故障恢复方法,（3） 检查点日志记录 检查点是在日志中周期设定的操作标志，目的是减少系统故障后的恢复的工作量。在检查点上，需要完成的操作： 将日志缓冲区中的内容写入外存中的日志； 在外存日志中登记一个检查点记录； 将数据库缓冲区的内容写入外存数据库； 把外存日志中检查点的地址写入重启动文件。 使检查点以前的工作持久化。当系统出现故障时，只对最近的检查点以后的操作进行恢复处理。,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,6、 基本的恢复操作 系统故障发生时，造成数据库不一致状态的原因为：一些未完成事务对数据库的更新已写入外存数
14、据库；一些已提交事务对数据库的更新还没写入外存数据库。因此，基本的恢复操作分两类，即反做（undo）和重做（redo）。反做（undo）也称撤消。 （1）反做（undo）反做（undo）是将一个数据项的值恢复到其修改之前的值，即取消一个事务所完成的操作结果（见图7.2所示）。当一个事务尚没提交时，如果缓冲区管理器允许该事务修改过的数据写到外存数据库，一旦此事务出现故障需废弃时，就需对被这个事务修改过的数据项进行反做（undo），即恢复到其前像。反做（undo）保持数据库的原子性。,7.2 集中式数据库的故障恢复方法,（2）重做（redo）重做（redo）是将一个数据项的值恢复到其修改后的值，即
15、恢复一个事务的操作结果（见图7.2所示）。当一个事务提交时，如果缓冲区管理器允许该事务修改过的数据不立刻写到外存数据库，一旦此事务出现故障，需对被这个事务修改过的数据项进行重做（redo），即恢复到其后像。重做（redo）保持数据库的永久性。,7.2 集中式数据库的故障恢复方法,例7.2.2有数据项x ,x值为10。设有一事务T，执行操作x=20。若执行过程中出现错误， 则： undo（T）：x=10;redo（T）：x=20; （3）重做（redo）和反做（undo）基本特性 如果在进行反做（undo）处理时又发生了故障，则要重新进行反做（undo）处理，所以对一事务的一次或多次反做（und
16、o）处理应是等价的，该特性称为反做（undo）的幂等率。 反做（undo）的幂等率表示为：undo（undo（T）= undo（T） 同理，重做（redo）也有幂等率特性。 重做（redo）的幂等率表示为：redo（redo（T）= redo（T） 重做（redo）和反做（undo）幂等率说明，对一个事务T执行任意多次redo/undo操作，其效果应与执行一次redo/undo操作的结果相同。,7.2 集中式数据库的故障恢复方法,7、先写日志协议（WAL（Write_ahead logging）系统的故障恢复是以日志文件为基础完成的，因此，要求事务在执行过程中满足先写日志协议（WAL）。当系统
17、发生故障时，可有效地采用重做（redo）和反做（undo）两个基本恢复操作进行恢复。 先写日志协议（WAL）含义： （1）在外存数据库被更新之前，应将日志文件中的反做信息写入外存文件； （2）事务提交之前，日志文件中的有关重做信息应在外存数据库更新之前写入外存文件。,7.2 集中式数据库的故障恢复方法,8、对内存信息丢失故障的恢复处理方法 假设缓冲区执行策略为no_fix/no_flush方式。 no_fix/no_flush方式故障表现为：废弃事务的部分修改的数据可能已写入外存；被提交的事务的更新数据可能没有被刷新到外存数据库。因此，其恢复操作过程为：对日志中只有“begin”，没有“end
18、”的事务全部进行反做（undo）处理；对日志中既有“begin”，又有“end”的事务部分进行重做（redo）处理。 （1）故障分析 事务的执行过程用树型结构图（见图7.6）来说明。 事务执行过程为：事务或执行结束或中断即废弃。若废弃，需反做（undo）处理，结束事务；若执行结束，进行提交或发生故障废弃。若废弃，反做（undo）处理，结束事务；若正确提交，将结果写入外存或发生故障部分结果未写入外存。若结果写入外存结束，事务正确执行结束，数据永久化；若部分结果未写入外存，需重做（redo）处理，结束事务。,7.2 集中式数据库的故障恢复方法,（2）故障恢复 当事务执行中出现故障时，需对事务进行重
19、做（redo）和反做（undo）恢复处理，具体恢复过程为： 恢复子系统首先从重启动文件中取得最近的检查点的地址，然后建立两个表：重做表和反做表。初始化两表，重做表初态为空；反做表初态为检查点上活动事务。活动事务指检查点上还没有结束的事务。 确定反做事务表（undo表）：在日志中从检查点向前搜索，直到日志结尾。找出只有B记录没有C记录的事务，即在系统故障时未结束的事务，写入反做事务表。 确定重做事务表（redo表）：从检查点向前搜索,找出既有B记录也有C记录的事务（将该事务从undo表删除），直到日志结尾,即在系统故障时已经提交但部分结果未写入外存的事务，写入重做事务表。 反做（undo）反做事
20、务表中的所有事务。根据日志反向进行撤消操作，直到相应事务的B(begin transaction). 重做（redo）重做事务表中的所有事务。根据日志从检查点正向进行重做操作，直到相应事务的C（commit transaction）。,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,7.2 集中式数据库的故障恢复方法,1、通信故障 通信故障有两种：报文丢失和网络分割。若存在两个结点A和B，报文丢失指A最大延迟内没有收到B发来的报文。网络分割指网络被断开或存在两个以上不相联接的子网。 如果系统不存在通信故障，则应表现如下情况：（1）收到的报文内容及报文顺序均正确；（2）无
21、超时错误发生。无超时错误指在发送报文后，在规定的延迟时间内应收到返回的应答信息。另外，除网络分割可能造成报文丢失外，场地故障也可造成报文丢失。 根据分布式数据库系统的特征，分布事务的执行是分解为若干个不同场地上的子事务的执行。因此，分布事务提交的先决条件是分布事务的所有子事务必须全部提交，否则事务全部废弃。为使分布式事务正确提交，通常采用两段提交协议（2PC）即基本的两阶段提交协议。,7.3 分布式事务的恢复,1、 具有恢复功能的两段提交协议（2PC） （1）两段提交协议（2PC） 两段提交协议（2PC）的思想概括地说是事务提交分两个阶段：决定阶段和执行阶段。决定阶段是作出提交/废弃的决定；执
22、行阶段实现决定阶段的决定。具体可用下面流程图描述（见图7.8）。 为说明两段提交协议，先介绍几个扩充的日志记录： Prepare记录：内容为事务标识（tid），Prepare代码； Ready记录：内容为事务标识（tid），Ready代码； Complete记录：内容为事务标识（tid），Complete代码。 Prepare记录、Ready记录和Complete记录简称P记录、R记录和C记录。,7.3 分布式事务的恢复,7.3 分布式事务的恢复,1、 场地故障的恢复处理 两段提交协议（2PC）具有恢复场地故障和通信故障的特性，下面以两段提交协议（2PC）实现的概要图(图7.9)，对场地故障的
23、恢复进行描述。,7.3 分布式事务的恢复,场地故障分析： （1） 故障：在参与者场地，参与者在写R/A记录之前出错。此时，协调者发完Prepare命令后在规定时间内收不到应答信息。 恢复：协调者发现超时，做Abort处理，即缺省认为收到Abort应答。,7.3 分布式事务的恢复,场地故障分析： （2）故障：在参与者场地，参与者在写R/A记录之后，写C/A记录之前出错。 恢复：故障场地重新启动，向协调者或其它场地重新请求命令（C/A）。,7.3 分布式事务的恢复,场地故障分析： （3）故障：在协调者场地，协调者在写P记录之后，写C/A记录之前出错。 恢复：协调者重新启动后，重新执行2PC协议。,
24、7.3 分布式事务的恢复,场地故障分析： （4）故障：在协调者场地，协调者在写C/A记录之后，写Complete记录之前出错。 恢复：没收到命令的参与者保持等待，协调者重新启动后，给所有参与者重发其决定的命令。,7.3 分布式事务的恢复,2、 通信故障的恢复 通信故障分报文丢失和网络分割两种。通信故障的直观表现是造成传输信息的丢失。丢失的信息可分为命令信息、响应信息及数据库信息。当命令或响应信息丢失时，直接影响事务的实现。 （1）报文丢失故障的恢复 根据丢失的报文信息类型（见图7.10），有下面几种情况： 丢失P命令报文；丢失R/A响应报文；丢失C/A命令报文；丢失ACK响应报文；,7.3 分
25、布式事务的恢复,根据丢失的报文信息类型（见图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 分布式事务的恢复,
