分布式系统容错.ppt

《分布式系统容错.ppt》由会员分享，可在线阅读，更多相关《分布式系统容错.ppt（116页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、第十一章 DDB的可靠性概念系统（System）是由一组组件构成的一种机制，这些构成组件通过响应来自某个环境的具有可识别行为模式的刺激而相互作用。component1component2component3环境系统刺激响应系统规范说明（Specification）系统提供的对所有可能的刺激将产生的响应行为必须遵循的说明概念-续故障任何偏离规范说明的行为软故障与硬故障软故障 间歇性（intermittent）和瞬变性（transient）故障硬故障 指永久性故障,错误设计等FaultErrorFailure原因结果导致系统失败的事件链概念-续软故障软故障 占90%以上并且该比例稳定67年 美空军

2、指出计算机中电子故障80%是间歇性的67年 IBM 指出 90%故障是间歇性的80年 研究指出软故障明显高于硬故障87年 Gray指出 大部分软件故障是瞬时性故障其它不同计算机系统中出现的统计数据:IBM/XA 的OS 可靠性报告 57%是硬件,12%软件,14%操作,7%环境（斯坦福 线性加速器SLAC）Tandem计算机 18%硬件 25%软件 25%维护 17%操作,14%环境AT&T 5ESS数字交换机 32.3%硬件,44.3%软件,17.5%操作 软件故障难以讨论,Tandem指出:通信或DB的原因是产生软件故障的主要原因.软件故障的主要原因 代码中的Bug,曾有报告指出,1000

3、条指令中,0.25-10个BUG永久性故障错误的设计不稳定或者临界的组件不稳定的外部环境操作者的过失系统失败永久性错误间歇性错误瞬变的错误系统失败的原因概念-续可靠性DDBMS 指即使当底层系统不可靠时，该DDBMS仍然能继续处理用户需求。也就是说，即使是分布式计算环境的组成出故障，该DDBMS 仍然能执行用户需求，而不破坏数据库的一致性。提交协议与恢复协议 可靠性与事务的原子性和持久性相关，涉及的协议是提交与恢复可靠性与可用性可靠性 对系统行为遵从某种权威性规格要求的一种度量。指在一给定时间间隔内不产生任何失败的概率。可靠性通常用于描述那些不能修复的系统。可用性 对系统行为遵从某种权威性规格

4、要求的一种度量。只在给定的时间点系统可以运行的概率。通常用于描述哪些可以修复的系统。可靠性与可用性-续DB行为所要求的规格说明与应用有关的 事务满足一般的系统规格要求,其中包括一致性约束(事务与应用之间的语义关系)与应用无关的 事务维持其ACID性质(事务本身应具有的性质)可靠性与可用性-续正确性 DB正确运行,符合某种规格化要求可用性 当需要访问DB时,它是可用的二者有时存在矛盾 可靠性与可用性-续例:Site1 Site2 x1 x2 Lock x1 Lock x2 2PC Ready故障出现Site1也Ready故CommitSite 2 等待此时Site 2有两种可能:a 以正确性为标

5、准 则等待,并Lock 2,直到故障恢复,但牺牲了可用性b 引入不一致,尽量提高可用性,Release x2,其它事务可以执行Site 1 正常结束分布式系统容错容错 设计一种使系统识别出可能会发生的错误方法。在系统中建立一种机制，使错误在造成系统故障之前就会被检测出来，并能被清除或得到补偿。基本容错方法和技术错误预防 保证所实现的系统不包含任何错误错误回避 保证系统不会带入错误的技术（详细的设计方法学和质量控制）错误清除 清查那些在使用了错误回避技术路线后还残留在系统中的错误，并清除它们（大量的测试和证实过程）故障检测基本容错方法和技术-续潜伏的（Latent）故障 故障发生一段时间后才被检

6、测出来 错误潜伏期 从故障发生到被检测出来的时间平均检测时间(MTTD)平均错误潜伏时间平均修复时间(MTTR)修复一个失败的系统所需要的期望时间平均故障间隔时间(MTBF)在可以自我修复的系统中相继的失败之间的期望时间,由经验或从可靠性函数计算 MTBF MTTDMTTR在这段时间内，可能发生多起错误故障发生造成错误检测到错误修复故障发生造成错误时间 相继发生的事件基本容错方法和技术-续冗余 所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余模块化 系统的每个组件都设计为具有定义很好的输入/输出接口的模块系统实现故障-停止模块（fail-stop module)进程对（Process

7、 pairs)time正常 停止 恢复 正常易失存储丢失稳定存储 ok故障-停止模块 不断地对自身进行检测，当检测到一个故障时，就自动停止。优点是缩短了故障检测的潜伏期。基本容错方法和技术-续基本容错方法和技术-续进程对（Process pairs)通过软件模块的双工来实现容错。两个进程，一个是主进程，一个是备份，它们同时提供同样的服务，主进程与备份进程都是基于故障-停止模块实现。锁定-步进方式自动检查点设置方式状态检查点设置方式Delta检查点设置方式持久进程对基本容错方法和技术-续面向对话的通信（Session-Oriented Communication)授权OS中的消息服务器（而不是应

8、用程序）去检测和控制那些丢失的或重复的消息分布式DBMS的故障事务故障站点故障介质故障通信故障局部可靠性协议局部恢复管理器(LRM)每个Site一个维护局部事务的原子性和持久性体系结构数据库存储在稳定存储器中存储和访问稳定数据库的单位是页缓冲区中的数据库称作易失数据库LRM仅仅在易失数据库上执行事务操作对数据库的访问都要经由数据库缓冲区管理器Flush(冲洗)实现将数据库缓冲区页对稳定DB的强迫写数据库缓冲区(易变数据库)局部恢复管理器数据库缓冲区管理器主存取出,冲洗读/写稳定DB读/写LRM与缓冲区管理器的接口局部可靠性协议-续恢复信息LogUndoRedo原位更新影子（shadowing）

9、更新旧的稳定DB状态新的稳定DB状态Redo数据库Log新的稳定DB状态旧的稳定DB状态Undo数据库Log局部可靠性协议-续目的 保证在DB上执行的事务的原子性和持久性。协议描述了原语的执行过程命令执行过程Begin-Trans 登录Read LRM先在Trans的缓冲区中读，若不在，则向缓冲区管理器发Fetch命令，读出数据后，LRM将它交给调度程序Write 若在Buffer中得到，则在那更新，否则对Buffer Manager发Fetch命令，数据的前像和修改后的后像写入LogAbort 通过Log做UndoCommit 将事务结束记录入Log项分布式可靠性协议目的：维持在多个数据库上

10、执行的事务的原子性和持久性原语Begin_Transread,write,Abort,commit,recover命令执行与局部协议类似Read/write 使用ROWA规则分布式可靠性协议-续可靠性协议组成 包括提交、终结、恢复协议终结协议 分布式系统特有的协议。若一个Site故障，希望其它Site也停止该事务。非阻断协议 允许Trans在非失效Site终结，而不必等待失效Site的恢复，改进Trans的响应时间。独立的恢复协议 如何在发生失效时终结Trans,而不必求助于其它Site,可以减少恢复时需要交换的信息。分布式可靠性协议-续终结协议与恢复协议的比较假若一个Site失效终结协议确定

11、了为失效Site如何处理该失效事件恢复协议确定失效Site重启动后，进程（协调者，参与者）恢复它的状态的过程网络分割时终结协议采取必要的措施来终结在不同网络区间执行的活动事务当网络重新连接后，恢复协议保证使各个冗余DB相互一致2PC协议简单的能保证分布式事务原子提交的协议协调者参与者申请-PREPAREPREPAREDCOMMITACK2PC-提交协 调 者参 与 者申请-PREPARENOABORTACK2PC-夭折集中式2PC协调者 参与者IWCAIRCAcommit-申请 申请-prepare*no abort*prepared*commit commit ACK 申请-prepare

12、prepared 申请-prepare no abort ACKF ACK*ACK*标记:输入消息 输出消息*=每一个当参与者进入“R”状态:它必定已获得所有资源它只能根据协调者指令提交或夭折当所有参与者是在“R”时,协调者才能进入“C”状态,即,它一定最终能提交2PC-续2PC讨论参与者可以单方面撤销Trans，直至它作出肯定性的提议（单方面中止的时间是在其作出肯定提议之前）一旦参与者确定了提交或撤销协议，它就不能更改它的提议。参与者处于Ready状态，可以根据协调者发来的消息种类，直接转为Abort/Commit全局提交必须是所有参与者共同作出的全局终结决定通信故障出现时，协调者和参与者可

13、能会出现互等状态2PC-续假撤销2PC和假提交2PC协议改善2PC的性能假撤销协议中，协调者不必等待参与者的ACK消息，减少了协调者与参与者之间传递消息的数量假提交协议中，可以不将Prepare写入Log，减少了Log写入的次数2PC的恢复协议参与者在Ready状态的恢复（1a）此时P重启时通过识别Log中有Ready记录，没有Commit/Abort记录判定其在Ready状态，重启时询问协调者或其它Site。协调者已发出Prepare命令此时恢复程序可识别出Log中有Prepare记录，但没有“G-commit”/“G-abort”记录，重发命令协调者已发出Global命令恢复时识别出Log

14、中“G-commit”/“G-abort”记录，重发命令2PC中远程Site恢复问题当P回答了Ready之后，还没有收到有关命令之前故障，需要远程Site之间交换信息，获取信息的方法有：向协调者询问 若此时C也故障，则得不到回答，P被阻断重定向询问 向其它P询问，此时只要有一个P收到命令，则该P也可以获得命令（要求有关结束事务的信息也必须在P站点保留)脱机方式 给每个Site分配一组脱机站点S(i),当i故障时，所有有关i的信息都送到S(i)保留Trans阻断与终结协议Trans阻断 某个Site上本来可以终结（提交或撤销）的子事务，由于DDBS故障，必须等待到故障恢复（其占有的资源不释放）阻

15、断协议 发生某类故障时，使分布式Trans处于阻断状态终结协议 允许事务在有故障情况下仍能正确结束Trans阻断与终结协议-续2PC协议是终结协议的条件至少有一个Site已收到结果命令（该Site可以告知其它参与者）没有一个参与者收到命令，并且只有协调者Site故障（可以新造协调者）2PC 阻断例:CoordP2R P1P3 RRP4R2PC的终结协议使用超时技术协调者超时在等待状态超时，可以决定“全局撤销”在撤销/提交状态超时，重发“G-abort”/“G-commit”参与者超时在初始状态超时，单方面Abort在Ready状态超时，被阻断，等待设计终结协议协调者超时IWCAFcommit-

16、申请申请-prepare*ack*-ack*-_t_abortanyabortanycommit_t_commit_t_abort*noabort*prepared*commit*t=timeout参与者超时IRCA申请-prepareprepared等价于结束状态_t_ pingabortackcommitack申请-preparenocommitackabortack2PC的终结协议-续设计(假设参与者之间可以通讯)假定Pi超时(Pi执行ping），其它Pj按如下响应Pj处于初始状态，于是单方面Abort，并回送“建议abort”给PiPj处于Ready状态，此时不能帮助Pi终结Pj处于C

17、ommit或Abort状态，此时向Pi发送“建议提交”或“建议Abort”Pi对Pj返回的响应，可能有的解释Pi收到Pj的“建议撤销”回答，此时Pi夭折Pi受到Pj“建议撤销”回答，但是其它Pj处于Ready状态，此时Pi仍然AbortPi收到Pj处于Ready状态，此时没有一个参与者有足够的信息恰当地终结事务Pi收到Pj”全局提交”或”全局夭折”消息，Pi可以根据消息终结Pi收到某些Pj的“全局提交”，而另一些Pj处于Ready状态，Pi可以提交非阻断协议允许Trans在非失效Site终结，而不必等待失效Site的恢复，改进Trans的响应时间。集中式2PC 协调者 参与者IWCAIRCAc

18、ommit-申请 申请-prepare*no abort*prepared*commit commit ACK 申请-prepare prepared 申请-prepare no abort ACKF ACK*ACK*标记:输入消息 输出消息*=每一个2PC 阻断例:协调者P2R P1P3 RRP4R非阻断协议提交协议是非阻断的充要条件是,在其状态转换图中不存在:没有状态是即与提交又与夭折状态“相邻”不存在不可提交状态是与提交状态“相邻”相邻 从一个状态直接转换到另一个状态非阻断协议-续2PC中,C(提交)状态是可提交状态,其它为不可提交状态Ready 状态是不可提交状态Wait状态是不可提交

19、状态它们都侵犯了非阻断协议的充要条件,从而考虑改变2PC,使其满足非阻断协议条件在Wait 和 Commit 之间,或者在Ready和Commit之间加入另一种状态作为缓冲状态,从而有了3PC协议IWACcommitpreparevote-abortglobal-abortvote-commitprepare-to-commitIRACpreparevote-commitglobal-abortACKprepare-to-commitready-to-commitpreparevote-abort3PC中事务的状态转换图PCPCready-to-commitglobal-commit glob

20、al-commitACK(a)协调者(b)参与者协调者参与者 申请-PREPAREPREPAREDCOMMITDONE PRECOMMITACK协调者参与者 申请-PREPARENOABORTDONE协调者参与者开始-3PC 记录写Log (参与者列表)commit记录写Log (状态C)prepared记录写Log (状态 W)committed 记录写Log (状态 C)申请-PREPAREPREPAREDCOMMIT PRECOMMITACK3PC协议中的超时处理协调者Wait状态超时 与2PC中协调者在Wait超时相同,协调者单方面AbortPC状态超时 此时协调者不知道每个相应的P是

21、否到达PC.但是知道每个P至少在Ready状态,因此协调者可以将所有P移入PC状态Commit/Abort状态超时 协调者不知P是否已执行命令,但是对Commit而言,知道P至少在PC状态3PC协议中的超时处理-续参与者超时Initial状态超时 与2PC中的情况相同Ready状态超时 知道P准备Commit.由于与协调者的通信丢失,终结协议将选举一个新的协调者PC状态超时 P已收到“Prepare-to-commit”,正在等待来自协调者的全面提交,处理同上协调者参与者 申请-PREPAREPREPAREDCOMMIT PRECOMMITACK1.超时:Abort2.超时:忽略1.超时t:a

22、bort2.超时:终结协议3.超时:终结协议终结协议开始 3PC协调者故障做出决定所有站点获得决定 仅仅工作的进程参与终结协议.恢复进程一直要等待到做出决定,然后获得该决定协调者参与者 申请-PREPAREPREPAREDCOMMIT PRECOMMITACK可以夭折(A)不确定(U)预提交(PC)提交(C)3PC协议例:协调者P2W P1P3WP4W3PC 原理如果每个工作的站点都处于“不确定”状态,没有站点(无论是工作的还是失败的)能够提交注:假定网络可靠终结协议竞选新的协调者使用竞选协议新协调者送出 REQUEST状态 给参与者使用终结规则做出决定与参与者通信协调者参与者 REQUEST

23、状态*ABORTABLE ABORT*协调者参与者 REQUEST状态*COMMITTED COMMIT*协调者参与者 REQUEST状态*UNCERTAIN*ABORT*协调者参与者 申请状态*预提交,ReadyCOMMIT*预提交*ACK*终结协议期间的故障站点故障协调者超时检测出来协调者忽略故障站点协调者故障某些站点超时启动竞选协议选择新协调者终结协议例:协调者P2W P1P3 WPCP4W终结协议新协调者工作如下在Wait状态 将全局Abort.此时P可以在任何状态,若P是在PC状态,即它是期望有“G-Commit”,但是得到了“G-Abort”.3PC中缺少从PC到Abort的转换,

24、这对终结协议很有用.在PC状态 此时没有P是在Abort状态,协调这可以全局提交,发送“G-Commit”命令.在Abort状态 所有P进入Abort状态恢复站点恢复站点发送“决策申请”等待响应只要不是全失败,就一定能获得响应全故障例:协调者P2 P1P3 WP4全故障恢复进程必须等待,直到单个独立的恢复进程P恢复P 响应决定申请故障恢复的最新进程恢复运行终结协议阻塞!恢复协议3PC与2PC恢复协议的差别很小协调者在Wait状态故障,终结协议P已终结事务,因此,协调者必须查询以决定事务的命运协调者在PC状态故障,终结协议已使工作的P终结,因此,协调者需询问P在PC状态故障,必须询问以确定其它参

25、与者如何终结事务习题 给出线性控制的2PC协议算法.网络分割简单分割多分割网络分割非阻断协议的存在性也可换成讨论:在站点故障时,是否存在允许独立恢复的协议独立恢复:指重启动时,无需远程访问若存在处理分割的非阻断协议,那么,该协议可使分割中的站点到达终结决定,而且这个决定与另一分割中的决定一致网络分割-续3PC不能从分割中恢复例:若发生了分割,但不是协调者故障.此时,协调者组和参与者组都认为其它站点有故障,把事务终结,但是不能保证他们是以同样的非阻断形式终结.所以,3PC是在网络分割时存在灾难性故障的风险条件下获得非阻断的性质.结论独立恢复协议只存在于单站点故障的情形若发生网络分割的时候,丢了报

26、文的话,则不存在任何非阻断的协议能从网络分割故障中恢复网络分割的终结协议能处理分割的协议 允许事务至少有一组站点来终止,于是阻断被减少主站点法2PC时 需要当所有挂起事务的协调者都属于此组,才可能使此站点的全部事务终止.3PC时 事务由主组的站点来终止网络分割的终结协议-续多数法和基于法定人数法在事务中止或提交前,大多数站点必须一致同意中止或提交基于法定人数的规则每个站点i有选票数Vi,Vi是正整数V=Vi事务在提交前必须收集提交选票数Vc事务在Abort前必须收集Abort选票数VaVa+VcVni=1例:协调者 P2 W P1P3 WP4 WN=5,多数=因为 P2,P3,P4 是多数,所

27、以它们知道没有它们的参与 协调者和 P1 不能“Commit”因此,T 事务可以Abort!网络分割的终结协议-续网络分割时,在每个分割部分选择一个新的协调者3PC中加入PA状态,从而不允许从Wait/Ready到Abort 状态的转换原因有多个协调者组织事务终结,不允许多个协调者得出不同的结论,因此希望协调者获得夭折的决定如果新协调者故障,它不知道提交或夭折的票数,这样参与者要得到明确的决定,与参与提交或夭折的法定人数Ready(或Wait)都不满足该需求,于是引入另一个状态Pre-Abort,该状态在Ready和Abort之间网络分割-续基于法定人数的3PC集中式协议选择一个新的协调者协调

28、者收集状态信息,并按如下规则执行1)若至少一个站点已Commit(Abort),则对其它站点发送Commit(Abort)命令2)若处于PC状态站点的票数=Vc,则发送Commit3)若PA状态站点的票数=Va,则发送Abort4)若PC状态站点的票数+Ready状态站点的票数=Vc,则发送PC命令给不确定站点,等待2)状态出现5)若PA状态站点的票数+Ready状态站点的票数=Va,则发送PA命令给不确定站点,等待3)状态出现6)否则,等待故障修复IWACcommitpreparevote-abortglobal-abortvote-commitprepare-to-commitIRACpr

29、eparevote-commitglobal-abortACKprepare-to-commitready-to-commitpreparevote-abort基于法定人数3PC中事务的状态转换图PCPCready-to-commitglobal-commit global-commitACK(a)协调者(b)参与者PAready-to-abortglobal-abortPAready-to-abortglobal-abort 协调者 参与者 PREPARE申请PREPAREDCOMMIT PRECOMMITPRECOMMIT-ACK 协调者 参与者 PREPARE 申请NOABORT PRE

30、ABORTPREABORT-ACK2多数规则保证了该多数组的任何决定都将被所有分组的决定采纳1453决定#2决定#1简单3PC 与 多数 3PC简单(基本)3PC仅仅工作的站点参与任何大小的分割组都可以commit/abort(即使是单站点都可以)全故障后,必须等待所有的站点恢复(阻塞)通信故障是不安全多数 3PC工作的和恢复的站点都可以参与只有占多数的分割组才能 commit/abort(阻塞)能处理通信故障非冗余与冗余数据库非冗余数据库任何需要访问存储在另一区域里的数据项的新事务都备阻断,等待网络修复位于同一区域里的数据项的并发访问有并发控制算法处理网络分割时有提交协议处理冗余数据库分割时

31、,副本可能位于不同的区域由复制协议处理网络分割的处理策略一致性与可用性的选择非冗余数据库处理网络分割的终结协议集中式协议 基于集中式并发控制算法(主站点法和主副本法)基于表决的协议冗余数据库处理网络分割的终结协议复制控制协议数据复制数据库站点 1站点 2站点 3数据项分片数据复制的目的高吞吐量较好的响应时间高可用性复制作为可选择的提交协议数据在多站点独立更新,使用“惰性复制协议”减少数据不一致问题.基本方法 每个副本看作一个独立的数据项X1X2X3Lockmgr X3Lockmgr X2Lockmgr X1TxiTxjTxk对象 X 有副本 X1,X2,X3Read(X):获取 X1 共享锁获

32、取 X2 共享锁获取 X3 共享锁分别读 X1,X2,X3事务结束时,释放 X1,X2,X3 锁X1lockmgrX3lockmgrX2lockmgrreadWrite(X):获取 X1 互斥锁获取 X2 互斥锁获取 X3 互斥锁写新值到 X1,X2,X3事务结束时,释放 X1,X2,X3 锁X1X3X2locklocklockwritewritewrite读锁和访问只对一个副本写锁全部,并且更新全部副本ROWA方法X1X2X3读者加锁写者发现冲突!ROWA 读可用性高写可用性低ROWA的改进(ROWA-A)ROWA-A 读一个写所有可获得协议 更新事务T的协调者向所有包含x副本的站点发送WT

33、(x),并等待执行(或拒绝)的确认.当不可获得站点恢复时,也将更新自己的数据库.但如果站点在T开始之前就不可获得,它们就可能没有注意到T的存在,以及T对x的更新.问题协调者认为不可获得的参与者仍然工作,并且更新了x,但是其确认没有到达协调者站点在事务启动时不可获得,随后恢复并开始执行事务ROWA-A于是,协调者在提交前要进行有效性验证检查所有不可获得的站点是否仍然不可获得,如果写调者收到一个响应,他就撤销T.若都是不可获得,则检查在WT(x)执行是可获得的站点仍然可获得,是则提交事务ROWA-A比ROWA协议能更好地适应失效,包括网络分割.基于法定人数的复制控制Gifford算法 读法定人数V

34、r,写法定人数VwVr+Vw V 避免读-写冲突Vw V/2 避免写-写冲突该算法确保了在两个不同区域上启动且访问同一数据的事务不会同时终结惰性复制协议只在一个或多个副本上执行更新,以后再将更新传播到所有副本上所有权参数 定义更新副本的权限,副本可以更新就称为主Copy(主站点),否则称辅Copy(辅站点)传播参数 定义何时把对一个副本的更新传播到包含该对象的其它副本刷新参数 定义了刷新事务的调度策略配置参数 描述站点和网络的特点惰性复制协议-续两类所有副本都可更新,副本的组所有权,延迟立即方式更新只有一个被更新的主站点(惰性主站点法)集中刷新方案:按需 每次提交执行查询时,执行所有收到的刷新

35、事务来刷新被查询读取的辅Copy,造成查询响应延迟成组刷新 根据应用刷新要求,成组执行刷新事务定期刷新 在固定时间间隔内触发刷新不一致性检测(1)网络的一致视图可靠性算法是假定:全部能工作的站点对网络的所有站点(包括其本身)的状态(即工作或故障)具有一致的视图决定网络的一致视图监视网络的状态 当站点状态发生转换时,能及时发现新的信息一致地传播给全部站点不一致性检测(2)假设广义的网络范围内每个站点有一状态表,每个站点一个表项,记录其工作/不工作任何程序能够在任一站点设置一个“看守”,当该站点变化状态时它就收到一个中断分割时,状态表和一致视图的意义站点只认为那些能和它通信的站点是工作的一致视图的

36、数目与分离的站点组数目一样多不一致性检测(3)监视网络的状态决定一站点是否工作时向它请求一个报文,然后等待到超时控制站点 (请求站点)受控站点受控站点周期性地发送I-an-up报文网络站点K-3UP站点K-2DOWN站点K-1站点KUPDOWN(状态)网络上站点的状态站点K控制站点K-3,即它检查来自K-3的I-am-up报文是否到达站点K负责发现站点K-1和K-2从不工作到工作的恢复上图中K-1和K-2不一定是有故障,它们可能在分割的另一组中图反映了站点K和K-3的网络视图不一致性检测(4)广播新的状态监视功能每次检测出一个状态变化,就即获此广播功能此功能可由若干站点并行激活,需要某种机构来

37、控制冲突状态表的每个新的版本附加一全局唯一的时间戳在I-am-up报文中包含当前状态表的版本号启动新状态表传播的站点首先执行同步以获得一时间戳不一致的检测方法(1)假设分割期间,在两个或多个站点组中已执行了若干事务,可能对同一数据片断的不同副本进行了独立更新比较各副本的内容,检查其是否相同航空订票系统采用版本号允许对数据项操作的副本是主副本,其它是孤立或隔离的副本不一致的检测方法(2)正常工作期间,全部副本都是主副本,并且互相一致,每分副本维持一个原版号和一个当前版本号网络分割时,每个孤立副本的原版号被置为当前版本号值,并且,直到分割修复为止,此原版号不会改变例子数据项x的副本x1,x2,x3

38、 存储在三个不同站点V1,V2,V3分别是x1,x2,x3的版本号不一致的检测方法(3)初始时,三份副本一致,所以有:V1=(0,2)V2=(0,2)V3=(0,2)发生一次分割,把x3从其它两个副本分开,多数法选择x2和x1为主副本,版本号变为V1=(0,2)V2=(0,2)V3=(2,2)网络分割期间,假设只更新主副本,版本号为V1=(0,3)V2=(0,3)V3=(2,2)修复后,可以看出x3未曾修改不一致的检测方法(4)假设分割时,只更新x3,版本号为V1=(0,2)V2=(0,2)V3=(2,3)此时若没有其它孤立副本,则可以用x3的更新施加到主副本,但若还有x4 V4=(2,3)则

39、即使x3与x4版本号相同也不能说其是一致的若主副本与孤立副本都更新过,版本号为V1=(0,3)V2=(0,3)V3=(2,3)不一致的解决方法不一致的解决办法与应用相关航空订票系统暂停订票,收集旅客请求,网络修复后再集中订票赋予各订票点的订票数小于总数检查点与冷启动(1)分布式数据库冷启动中,一个站点要建立一早期状态,那么所有其它站点也必须建立起与该站点一致的早期状态,这意味着此恢复过程本质上是全局的,要影响到数据库的全部站点,虽然引起冷启动的故障一般讲是本地的.检查点冷启动(2)一致的全局状态C的两个特征对于每个事务T,C包含了T在任何站点的全部事务所执行的更新,或者它不包含它们中的任何一个

40、,称T被包含在C中如果一事务T被包含在C中,则按串行化次序,在T前面的全部冲突事务也包含在C中重构全局一致状态的最简单办法是使用本地的转储,本地的运行纪录,全局的检查点检查点冷启动(3)如果有全局检查点,则重构就相对容易.在故障站点出决定认为是安全的最近的一个本地检查点,然后请求所有其它站点重新建立相对应的本地检查点的本地状态问题是,只有一个站点把一“写检查点”报文广播给所有其它站点是不够的,因为可能出现如下情况站点1站点1站点1C1时间T2C2C3T3RC其中：T2和T3是事务T的子事务，T3是两阶段提交的协调者。C1、C2和C3 是本地检查点(从站点1开始)写检查点报文 两阶段提交的报文(

41、R=READY,C=COMMIT)全局检查点的同步问题检查点冷启动(4)避免上述问题的简单办法是,要求在每个站点记录其本地检查点之前,使所有站点变成不活跃的.全部站点必须同时停留在不活跃状态,需要进行协调,使用与2PC类似的协议更高效的方法是松散同步检查点 一个协调者来要求所有站点记录一全局检查点,但是它们可在以较大的时间间隔内自由地执行之,保证同一事务的全部子事务都包含在相应于同一全局检查点的本地检查点的责任交事务管理起承担检查点冷启动(5)每个站点独立于其它站点记录其本地检查点,所以建立一致全局状态由冷启动过程实现改进2PC,是属于两各分布事务T和T的所有子事务的检查点在执行这两个事务的所有站点中都以同样的次序记录总结设计一个可靠性好的分布式数据库时,要考虑采用2PC保证在故障下,所有站点的事务能正确提交或撤销,某些情况下事务被阻断,直到故障修复,由于加锁资源,降低可用性采用3PC消除上面提到的缺点,允许站点故障时终结事务,从而释放资源总结-续网络分割时,难于找到一种并发控制方法保证事务的可串行性,所以若所有站点的事务都处理,那么有可能产生不一致.不一致要到故障修复时才能检测出来灾难性故障发生时,采用冷启动.