第七章 分布式恢复

第七章分布式恢复基本概念集中式数据库的故障恢复方法分布式事务的恢复ReliabilityProblem:Howtomaintain(1)atomicity(2)durabilitypropertiesoftransactionsSpecificreliabilityprotocolsrelatedinclude:(1)commitprotocols,and(2)recoveryprotocols.§7.1基本概念1、可靠性和可用性分布式数据库系统本身的体系结构可提高系统的可靠性和可用性；片段数据的重复存储和系统采用的恢复措施等都可提高系统的可靠性和可用性。可靠性和可用性的具体描述如下：可靠性（Reliability）体现下面几点：•一个系统符合其行为规范的量度；•系统在给定时间间隔内不出故障的概率；•用来描述不可修复的或要求连续操作的系统的重要指标。可用性（Availability）体现下面几点：•系统可满足其规范的时间百分率；•系统在给定时间t上正常运行的概率；§7.1基本概念2故障模型恢复是数据库系统在系统出现故障的情况下采取的补救措施，使系统恢复到出错前的正确状态，系统恢复正确后，可继续运行，不会因系统故障造成数据库损坏和数据丢失。归纳系统可能出现的故障，可分为Fault(故障)、Error(错误)和Failure(失效)三种故障形式。故障模型（见图7.1）。§7.1基本概念说明：•刺激：来自外界的影响；•响应：来自于系统的信息；•内部状态：系统内部的状态；•外部状态：系统所处环境内的系统的外部状态；§7.1基本概念下面介绍三种故障形式为：Fault(故障)：指系统单元所处的内部状态发生的错误或系统内设计错误。Error(错误)：指出现了不正确的状态。Failure(失效)：指系统的外部状态中的错误。通常，由于Fault(故障)引发Error(错误)；由Error(错误)导致执行失效，即Failure(失效)。如下图所示：FaultErrorFailure导致引起CausesResultsin3、故障类型系统故障常分为两大类：硬故障和软故障。硬故障通常是永久的，不能自动修复。如：系统硬件设备（永久存储设备）的故障导致的系统数据丢失故障。硬故障导致的failure(失效)，称为硬失效。这种故障对数据库系统是致命的，应尽力避免。软故障通常是临时性或间歇性的。如：由于故障使数据库数据丢失或出错，使事务不能正确提交；系统死锁或算术溢出、被零除等造成的系统错误等。这些故障大多是临时性的，多是由于系统不稳定造成的，较容易恢复。如：系统可通过恢复机制进行恢复或重新启动事务恢复。通常这些软故障导致的failure(失效)，称为软失效。系统的failure90%是软失效。图7.2说明了故障的分类。§7.1基本概念§7.1基本概念(MeanTimebetweenFailures)(MeanTimetoRepair)(MeanTimetoDetect)5、分布库系统中的故障分布式数据库系统主要由结点及结点间的通讯链路组成。因此，在分布式数据库系统中，除了可能出现集中式数据库系统可能出现的故障外，还可能出现分布式数据库系统特有的故障，如：通信链路故障等。根据分布式数据库特点，其故障可归纳如下类型：(1)事务故障事务故障主要由系统单个事务或系统死锁引起的，使事务被废弃。如：算术溢出、被零除、超时、申请资源过多等。通常一个系统约有3%的事务被异常废弃。这一类故障不会导致存储介质上的数据被破坏，是一种影响性较小的可排除性的局部故障，由系统恢复机制自动恢复或重新启动事务来恢复。§7.1基本概念（2）系统（场地）故障系统（场地）故障主要由处理器、主存、电源、系统过载、系统崩溃等等造成的，往往涉及多个或全部事务，造成系统局部或系统全部出现故障。这类故障使主存的内容丢失，但外存的内容是安全的。（3）介质故障介质故障是由于外存设备故障引起的，如：磁头坏、驱动卡坏、扇区坏等。这类故障对数据库系统是致命的，导致外存数据部分或全部丢失。（4）通讯故障通讯故障主要指报文丢失和网络分割。报文丢失是指在传送过程中由于报文丢失而导致的数据错误。网络分割是指系统的一个场地与另一场地失去联系，使两场地间无法通讯。§7.1基本概念集中式数据库的故障分为硬故障和软故障两类。故障主要体现在是事务永久性的，还是间歇性的；是导致了外存数据错误，还是使内存数据发生错误。针对可能产生的不同故障，应采用相应的故障恢复方法。介绍故障恢复之前，了解一下数据库中数据的更新方法、缓冲区中数据更新方法等内容。1、局部恢复系统的体系结构尽管系统可能出现有各式各样的故障，但故障恢复的系统体系结构是一致的。§7.2集中式数据库的故障恢复方法2、数据库更新策略数据库数据的更新通常采用两种更新方法，即原地更新和异地更新。原地更新是指数据库的更新操作直接修改数据库缓冲区中的旧值。异地更新是指数据库的更新操作将数据项新值存在于旧值不同的位置上。如：采用影子页面（shadowingpage）或采用差分文件方式存储。影子页面是指当更新数据时，不改变旧存储页面，而是建一影子页面，将新值存于新建的影子页面上。而旧页面用于故障恢复。差分文件（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/no_flush。固定/非固定（fix/non_fix）是指缓冲区管理器是否等到局部恢复管理器（LRM）发的命令后，才将缓冲区中修改的内容写到外存数据库。刷新/非刷新(flush/no_flush)是指在事务执行结束后，局部恢复管理器（LRM）是否强制缓冲区管理器将其中已修改的数据写回外存数据库。§7.2集中式数据库的故障恢复方法4、不同执行策略的恢复要求(1)fix/flush方式--废弃事务时没有将修改的数据写入外存。因为在事务结束之前，所修改的数据页面已被固定，直到事务提交时，才被释放。同时需释放所有被固定的页面。被提交的事务的更新数据都刷新到外存数据库。其处理过程：①LRM向缓冲区管理器发flush命令，将更新数据刷新到外存；②LRM向缓冲区管理器发unfix命令释放所有被固定的页面；③LRM向日志文件中写事务结束记录。该种执行策略对废弃事务不需做任何恢复操作。§7.2集中式数据库的故障恢复方法4、不同执行策略的恢复要求(2)fix/noflush方式--废弃事务没有将修改的数据写入外存。被提交的事务的更新数据可能没有被刷新到外存数据库。因为其处理过程为：①LRM向日志文件中写事务结束记录；②LRM向缓冲区管理器发unfix命令释放所有被固定的页面。该种执行策略的事务恢复需执行部分重做（redo），不需执行全局反做（undo）处理。§7.2集中式数据库的故障恢复方法(3)no_fix/flush方式--废弃事务的部分结果可能已被写入外存。被提交的事务的更新数据都刷新到外存数据库，处理过程为：①LRM向缓冲区管理器发flush命令，将更新数据刷新到外存；②LRM向日志文件中写事务结束记录。该种执行策略的事务恢复操作应需对事务全部进行反做（undo）处理，不需要重做(redo)。§7.2集中式数据库的故障恢复方法(4)no_fix/no_flush方式–废弃事务的部分修改的数据可能已写入外存。被提交的事务的更新数据可能没有被刷新到外存数据库。因为其处理过程为:LRM向日志文件中写事务结束记录。该种执行策略的事务恢复操作过程为：①LRM对日志中只有“begin”，没有“end”的事务全部进行反做（undo）处理；②LRM对日志中既有“begin”，又有“end”的事务部分进行重做（redo）处理；§7.2集中式数据库的故障恢复方法§7.2集中式数据库的故障恢复方法在日志中，系统的运行情况以运行记录的形式存放，日志中具体存放信息如下：（1）数据日志记录内容为：•事务标识符；•操作类型；•操作的数据项；•数据项的旧值；•数据项的新值；（2）命令日志记录内容为：•事务标识符；•命令（如：begin,abort,commit）；§7.2集中式数据库的故障恢复方法（3）检查点日志记录检查点是在日志中周期设定的操作标志，目的是减少系统故障后的恢复的工作量。在检查点上，需要完成的操作：①将日志缓冲区中的内容写入外存中的日志；②在外存日志中登记一个检查点记录；③将数据库缓冲区的内容写入外存数据库；④把外存日志中检查点的地址写入重启动文件。使检查点以前的工作持久化。当系统出现故障时，只对最近的检查点以后的操作进行恢复处理。§7.2集中式数据库的故障恢复方法§7.2集中式数据库的故障恢复方法6、基本的恢复操作系统故障发生时，造成数据库不一致状态的原因为：①一些未完成事务对数据库的更新已写入外存数据库；②一些已提交事务对数据库的更新还没写入外存数据库。因此，基本的恢复操作分两类，即反做（undo）和重做（redo）。反做（undo）也称撤消。（1）反做（undo）反做（undo）是将一个数据项的值恢复到其修改之前的值，即取消一个事务所完成的操作结果（见图7.2所示）。当一个事务尚没提交时，如果缓冲区管理器允许该事务修改过的数据写到外存数据库，一旦此事务出现故障需废弃时，就需对被这个事务修改过的数据项进行反做（undo），即恢复到其前像。反做（undo）保持数据库的原子性。§7.2集中式数据库的故障恢复方法（2）重做（redo）重做（redo）是将一个数据项的值恢复到其修改后的值，即恢复一个事务的操作结果（见图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）处理，所以对一事务的一次或多次反做（undo）处理应是等价的，该特性称为反做（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_aheadlogging））系统的故障恢复是以日志文件为基础完成的，因此，要求事务在执行过程中满足先写日志协议（WAL）。当系统发生故障时，可有效地采用重做（redo）和反做（undo）两个基本恢复操作进行恢复。先写日志协议（WAL）含义：（1）在外存数据库被更新之前，应将日志文件中的反做信息写入外存文件；（2）事务提交之前，日志文件中的有关重做信息应在外存数据库更新之前写入外存文件。§7.2集中式数据库的故障恢复方法8、对内存信息丢失故障的恢复处理方法假设缓冲区执行策略为no_fix/no_flush方式。no_fix/no_flush方式故障表现为：废弃事务的部分修改的数据可能已写入外存；被提交的事务的更新数据可能没有被刷新到外存数据库。因此，其恢复操作过程为：对日志中只有“begin”，没有“end”的事务全部进行反做（undo）处理；对