分布式数据库中的可靠性PPT课件下载推荐.ppt

分布式数据库中的可靠性PPT课件下载推荐.ppt

《分布式数据库中的可靠性PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《分布式数据库中的可靠性PPT课件下载推荐.ppt（79页珍藏版）》请在冰豆网上搜索。

提高了可靠性，但牺牲了可用性。

策略二：

在数据库中引入不一致性的风险下尽量提高可用性，解锁x2,其它事务可以使用它的值。

两阶段提交协议实现了第一个策略，牺牲可用性获得高可靠性；

如果要得到高可用性，就要考虑使用第二个策略。

Site1正常结束,已知：

x1和x2是x的副本；

事务T是更新x的事务；

Site1是协调站点且是事务T原发站点；

遵守两阶段提交协议。

通常使用两个参数的指标来度量一个分布式数据库的可靠性程度：

平均故障间隔时间MTBF和平均修复时间MTTR。

平均故障间隔时间MTBF指在可以自我修复的系统中相继失败之间的期望时间；

通过可靠性函数R（t）来计算MTBF=0R（t）dt可靠性函数R（t）与系统失败的概率有直接的关系。

平均修复时间MTTR是指修复一个失败的系统所需要的期望时间。

它与失败概率有关指数型失败和修复的概率的系统可用性可以描述为：

A=MTBF/（MTBF+MTTR）,可用性系统5个9（99.999%）常用来描述可用性系统；

建立一个高可用性系统比建立一个通常要求的系统要花费更高的成本（时间、人力、财力等）。

具体设计时要仔细分析，与最终用户商定，以确定用户可以忍受多长的停机时间，以及停机可能造成的影响，并且明确说明高可用性系统的成本。

故障任何偏离规范说明的行为称为故障。

软故障和硬故障软故障包括间歇性（intermittent）和瞬变性（transient）故障，通过重启动来修复；

硬故障指永久性故障,错误设计等。

软故障占90%以上并且该比例稳定67年，美空军指出计算机中电子器件故障80%是间歇性的67年，IBM指出90%故障是间歇性的80年，研究指出软故障的发生明显高于硬故障87年，Gray指出大部分软件故障是瞬变性故障,软件故障通信或数据库的原因是产生软件故障的主要原因。

软件故障的典型原因是代码中的Bug,曾有报告指出,1000条指令中,0.25-10个BUG。

软件故障难以排除，一个典型的软件工程在到达测试阶段以前，要经过大量的设计审查和代码检验。

审查不同计算机系统中出错的统计数据IBM/XA的OS可靠性报告57%是硬件,12%软件,14%操作,7%环境（斯坦福线性加速器SLAC）Tandem计算机18%硬件25%软件25%维护17%操作,14%环境AT&

T5ESS数字交换机32.3%硬件,44.3%软件,17.5%操作,永久性故障,错误的设计,不稳定或者临界的组件,不稳定的外部环境,操作者的过失,系统失败,永久性错误,间歇性错误,瞬变的错误,系统失败的原因,容错设计出一种使系统识别出可能会发生的错误的方法。

在系统中建立一种机制，使错误在造成系统故障之前就会被检测出来，并能被清除或得到补偿。

错误预防技术保证所实现的系统不包含任何错误。

错误预防有两个方面：

错误回避：

保证系统不会带入错误的技术（详细的设计方法学和质量控制）错误清除：

清查那些在使用了错误回避技术路线后还残留在系统中的错误，并清除它们（需要大量的测试和证实过程）,故障检测潜伏的故障：

故障发生一段时间后才被检测出来；

错误潜伏期：

从故障发生到被检测出来的时间；

平均检测时间（MTTD）：

平均错误潜伏时间；

平均修复时间（MTTR）：

修复一个失败的系统所需要的期望时间；

平均故障间隔时间（MTBF）：

在可以自我修复的系统中相继的失败之间的期望时间,由经验或从可靠性函数计算。

MTBF,MTTD,MTTR,在这段时间内，可能发生多起错误,故障发生,造成错误,检测到错误,修复,故障发生,造成错误,时间,相继发生的事件,冗余所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余。

对冗余的附加和补充的容错原则是设计的模块化。

模块化系统的每个组件被设计为具有定义很好的输入/输出接口的模块。

模块化可以把故障隔离在单一的组件中。

容错系统实现故障-停止模块（fail-stopmodule）进程对（Processpairs）,time正常停止恢复正常,易失存储丢失,稳定存储ok,故障-停止模块不断地对自身进行检测，当检测到一个故障时，就自动停止。

优点是缩短了故障检测的潜伏期。

进程对（Processpairs）通过软件模块的双工来实现容错。

它的思想是通过两个相互通信和合作的进程，完成系统的每一个服务的方法来减少单个的故障点。

这两个进程中的一个叫做主进程，另外一个叫备份进程，它们同时提供同样的服务，主进程与备份进程都是基于故障-停止模块实现。

进程对机制要求进程之间进行通信，可以通过共享存储区的手段来实现进程之间的通信。

当设计一个可靠的软件环境时，使用基于消息传送的通信机制来实现一个操作系统是非常重要的。

由于每个进程都在自己的地址区间内执行，一个进程可能发生的错误就不会传播到另外一个进程，这种方法可以有效地进行错误隔离。

目的分布式数据库可靠性协议是为了保证在分布式数据库上执行的分布式事务的原子性和持久性。

这些协议描述了begin-transaction,read,write,abort,commit和recover原语的分布式执行过程。

原语Begin_Transaction：

该命令执行登记的功能；

Read：

该命令指定一个数据项；

LRM先在Trans的缓冲区中读，若不在，则向缓冲区管理器发Fetch命令，读出数据后，LRM将它交给调度程序。

Write：

该命令指定了数据项和新值。

若在Buffer中得到，则在那更新，否则对BufferManager发Fetch命令，读出数据并修改，同时数据的前像和修改后的后像写入Log。

Abort：

该命令是异常终结事务处理失败的一个信号。

LTM读取相应的事务处理日志，并且用数据项的前值取代在易变数据库中的更新后的数据项的值。

同时，调度程序被告知异常终结已经被成功地完成。

Commit：

该命令使LTM将一个事务处理结束记录写入日志中。

分布式数据库系统的可靠性协议组成包括提交协议、终结协议、恢复协议。

提交和恢复协议详细说明了提交命令和恢复命令是如何被执行的。

终结协议是分布式系统特有的协议。

在执行一个分布式事务时，若一个站点有故障，希望其它站点也停止该事务。

处理这种情况的技术就称为终结协议。

终结协议与恢复协议的比较假若一个站点失效终结协议确定了未失效站点如何处理该失效事件；

恢复协议确定失效站点重启动后，进程（协调者，参与者）恢复它的状态的过程。

网络分割时终结协议采取必要的措施终结在不同网络区间执行的活动事务；

当网络重新连接后，恢复协议保证使各个冗余数据库相互一致。

两阶段提交协议的要点:

将本地原子性提交行为的效果扩展到分布式事务,保证分布式事务提交的原子性,在不损坏日志情况下,实现快速故障恢复，提高DDB系统的可靠性。

两阶段提交协议把事务的提交过程分为两个阶段：

第一阶段：

表决阶段，即形成一个共同的决定。

第二阶段：

执行阶段，目的是实现这个决定。

允许参与者单方面撤销事务，直到做出肯定性的建议；

一旦参与者确定了提交或者撤销提议，它不能再更改它的提议；

当参与者处于就绪状态，根据协调者发出的消息的种类，它可转换为相应的提交或者撤销状态；

协调者依据全局提交规则作出全局终结决定；

在发生故障的情况下，协调者和参与者可能会进入互相等待的状态，一般采用定时器来解决这种问题。

每个进程进入一个状态时都要设置定时器。

如果所期待的消息在定时器超时之前没有到来，定时器向进程报警，进程于是调用它自己的超时协议。

初始,写begin_commit到日志,等待,有要求撤消的？

写commit到日志,提交,写end_of_trans.到日志,初始,准备提交？

写ready到日志,就绪,消息类型？

写abort到日志,写commit到日志,提交,撤消,撤消,写abort到日志,写abort到日志,协调者,参与者,no,no,abort,commit,发送准备消息,发送“建议撤消”消息,发送“建议提交”消息,发送“全局撤消”消息,发送“全局提交”消息,ACK,发送”应答ACK确认”消息,两阶段提交协议的活动,yes,yes,假定撤销2PC和假定提交2PC协议这两种协议的基本思想是：

只要当一个已就绪的参与者向协调者询问事务的结果时，如果在协调者的日志中找不到该事务的任何信息，就认为该事务“被撤销”（对假定撤销2PC协议）或“已经提交”（对假定提交2PC协议）。

目的是改善2PC的性能；

假定撤销2PC协议中，协调者不必等待参与者的ACK消息，减少了协调者与参与者之间传递消息的数量；

当使用假定撤销2PC协议时，可以看出协调者在决定撤销后，可以立即忘记该事务。

它可以写入撤销记录，且不用等待参与者确认撤销命令。

写入撤销记录后，协调者无需写入事务结束记录。

假定撤销2PC和假定提交2PC协议假定提交2PC协议中，可以不将Prepare写入Log，减少了Log写入的次数；

如果使用假定提交2PC协议，协调者在发送准备消息之前，强制性写入一条收集记录，它包含了参与执行事务的所有参与者的名字，此时协调者进入收集状态。

随后协调者发送准备消息并进入等待状态。

当参与者收到准备消息后，以“建议撤销”或者以“建议提交”消息响应。

当协调者收到所有参与者的决定后，它就可以作出该事务是撤销或提交的决定。

如果决定撤销，协调者写入撤销记录，进入撤销状态，并发送“全局撤销”命令，直到协调者收到参与者的撤销确认，就写入一条结束记录，并忘记该事务。

如果它决定提交该事务，就写入提交记录，发送“全局提交”消息，然后忘记该事务。

当参与者收到“全局提交”消息后，它们写入提交记录，并更新数据库。

如果参与者收到“全局撤销”消息，它们写入撤销记录并确认。

事务阻断：

某个站点上本来可以终结（提交或撤销）的子事务，由于分布式数据库系统的故障，它必须等到有故障的子事务修复后，取得必要的信息才能决定。

故障的恢复是不可预料，所以它占有的资源也不能释放，也没法继续执行，此时称该事务处于事务阻断状态。

阻断协议：

提交协议称为阻断协议是指发生某类故障时，使分布式事务可能处于阻断状态。

在两阶段提交协议中，如果在提交阶段协调者出故障，若某个参与者与此同时宣布其已就绪提交，它必须等到协调者修复后，才能决定是否提交。

在这种情况下，两阶段提交协议是阻断协议。

事务阻断降低了系统的可用性，因为它们持有的锁不能被释放。

终结协议：

允许一事务在有故障情况下仍能正确地结束。

它提高系统的可用性。

当正常的提交过程被故障中断时，就调用终结协议，使无故障的站点正确地终结该事务。

终结的可能类型（提交还是撤销）依赖于当事务被故障中断时提交协议使它处于什么状态。

终结协议仅对某些类型的故障起作用，而不是对所有故障都起作用。

判断2PC协议是终结协议的条件至少有一个站点已收到结果命令。

此时，可由该站点告诉其它参与者关于该事务的结果，并由它们来终结该事务。

没有一个参与者曾收到过结果命令，并且只有协调者站点出故障。

此时，所有参与者站点都是可工作的，参与者可以选举一个新的协调者，然后继续。

没有一个可工作的参与者曾收到此命令，