《2019第6章分布式数据库中的可靠性ppt课件》由会员分享，可在线阅读，更多相关《2019第6章分布式数据库中的可靠性ppt课件（88页珍藏版）》请在金锄头文库上搜索。
1、分布式数据库系统及其应用,周韡（zhouwbjcn.ibm),分布式数据库的可靠性的概念及其度量 分布式数据库系统的故障原因和容错技术 分布式数据库的可靠性协议 网络分割和提交协议 不一致性监测和解决方法,分布式数据库中的可靠性,第6章,可靠性 指数据库在一给定时间间隔内不产生任何失败的概率。 它强调数据库的正确性，要求数据库正确运行，既符合某种规格化要求。 通常用来描述不可修复的系统。 可用性 强调的是当需要访问数据库时，它是可用的。 指在给定的时间点系统可以正常运行的概率。 通常用于描述那些可以修复的系统。 两者关系 通常认为构建可用性的系统比可靠性的系统容易 两者是统一的，可靠性高的系统
2、可用性自然是好的 两者又是矛盾的，增加错误风险的情况下，可提高可用性;采用太谨慎的策略会降低可用性,例: Site1 Site2 x1 x2 Lock x1 Lock x2 2PC,Ready,故障出现,Site1也Ready 故Commit,Site 2 等待,此时Site 2有两种可能: a 以正确性为标准，x2则等待, 并Lock 2, 直到故障恢复。提高了可靠性，但牺牲了可用性。 b 引入不一致性的风险下, 尽量提高可用性，解锁x2, 其它事务可以使用它的值。,Site 1 正常结束,已知 x1和x2是x的副本 事务T是更新x的事务 Site 1是协调站点 Site 1是事务T原发站点
3、 遵守两阶段提交协议,平均故障间隔时间 指在可以自我修复的系统中相继失败之间的期望时间 通过可靠性函数来计算MTBF=0R(t)dt MTBF与系统失败的概率有直接的关系 平均修复时间 是指修复一个系统所需要的期望时间，MTTR 它与失败概率有关 指数型失败和修复的概率的系统可用性 A=MTBF/(MTBF+MTTR) 可用性系统 5个9（99.999%）常用来描述可用性系统 但是可用性系统要求的成本比较高 具体设计时要综合用户两方面的要求,系统（System） 是由一组组件构成的一种机制，这些组件通过响应来自某个环境的具有可识别行为模式的刺激而相互作用。,component1,compone
4、nt2,component3,环境,系统,刺激,响应,系统规范说明（Specification） 系统提供的对所有可能的刺激将产生的响应行为必须遵循的说明,故障 任何偏离规范说明的行为 软故障和硬故障 软故障包括间歇性（intermittent）和瞬变性（transient）故障，通过重启动来修复 硬故障指永久性故障, 错误设计等 软件和硬件故障,软故障 占90%以上并且该比例稳定 67年， 美空军指出计算机中电子故障80%是间歇性的 67年，IBM 指出 90%故障是间歇性的 80年，研究指出软故障明显高于硬故障 87年，Gray指出 大部分软件故障是瞬变性故障,审查不同计算机系统中出错的统
5、计数据 IBM/XA 的OS 可靠性报告 57%是硬件, 12% 软件, 14%操作, 7% 环境（斯坦福 线性加速器SLAC） Tandem计算机 18%硬件 25% 软件 25%维护 17%操作, 14%环境 AT&T 5ESS数字交换机 32.3%硬件, 44.3%软件, 17.5%操作 软件故障 通信或DB的原因是产生软件故障的主要原因. 代码中的Bug, 曾有报告指出, 1000条指令中, 0.25-10个BUG,永久性 故障,错误的 设计,不稳定 或者 临界的 组件,不稳定的 外部环境,操作者 的过失,系 统 失 败,永久性 错误,间歇性 错误,瞬变的 错误,系统失败的原因,容错
6、设计一种使系统识别出可能会发生的错误的方法。在系统中建立一种机制，使错误在造成系统故障之前就会被检测出来，并能被清除或得到补偿。 错误预防 保证所实现的系统不包含任何错误 错误回避：保证系统不会带入错误的技术（详细的设计方法学和质量控制） 错误清除：清查那些在使用了错误回避技术路线后还残留在系统中的错误，并清除它们（需要大量的测试和证实过程）,故障检测 潜伏的故障：故障发生一段时间后才被检测出来 错误潜伏期：从故障发生到被检测出来的时间 平均检测时间(MTTD)：平均错误潜伏时间 平均修复时间(MTTR)：修复一个失败的系统所需要的期望时间 平均故障间隔时间(MTBF)：在可以自我修复的系统中
7、相继的失败之间的期望时间, 由经验或从可靠性函数计算,MTBF,MTTD,MTTR,在这段时间内， 可能发生多起错误,故障 发生,造成 错误,检测到 错误,修复,故障 发生,造成 错误,时间,相继发生的事件,冗余 所有容错系统设计中都采用的基本原则是在系统的组件中提供冗余 模块化 系统的每个组件都设计为具有定义很好的输入/输出接口的模块 模块化可以把故障隔离在单一的组件中 系统实现 故障-停止模块（fail-stop module) 进程对（Process pairs),time 正常 停止 恢复 正常,易失存储丢失,稳定存储 ok,故障-停止模块 不断地对自身进行检测，当检测到一个故障时，就
8、自动停止。 优点是缩短了故障检测的潜伏期。,进程对（Process pairs) 通过软件模块的双工来实现容错。两个进程，一个是主进程，一个是备份，它们同时提供同样的服务，主进程与备份进程都是基于故障-停止模块实现。 分类方式（根据主进程和备份进程之间的通信方式） 锁定-步进方式 自动检查点设置方式 状态检查点设置方式 Delta检查点设置方式 持久进程对,事务故障 系统故障 介质故障 通信故障,站点故障,局部恢复管理器 (LRM) 每个站点一个 维护局部事务的原子性和持久性 体系结构 数据库存储在稳定存储器中 存储和访问稳定数据库的单位是页面 缓冲区中的数据库称作易失数据库 LRM仅仅在易失
9、数据库上执行事务操作 对数据库的访问都要经由数据库缓冲区管理器 Flush(冲洗) 实现将数据库缓冲区页对稳定DB的强迫写,数据库 缓冲区 (易变数据库),局部恢复 管理器,数据库缓冲区 管理器,主存,取出, 冲洗,读/写,稳定 DB,读/写,LRM与缓冲区管理器的接口,恢复信息 Log Undo Redo,目的 保证在DB上执行的事务的原子性和持久性。 协议描述了原语的执行过程 命令执行过程 Begin-Transacrion：登录 Read：LRM先在Trans的缓冲区中读，若不在，则向缓冲区管理器发Fetch命令，读出数据后，LRM将它交给调度程序 Write：若在Buffer中得到，则
10、在那更新，否则对Buffer Manager发Fetch命令，读出数据并修改，同时数据的前像和修改后的后像写入Log Abort：通过Log做Undo Commit：将事务结束记录入Log项,目的 维持在多个数据库上执行的事务的原子性和持久性 原语 Begin_Transaction read, write, Abort, commit 命令执行与局部协议类似,可靠性协议组成 包括提交、终结、恢复协议 提交和恢复协议详细说明提交命令和恢复命令是如何执行的 终结协议是分布式系统特有的协议。在执行一个分布式事务时，若一个Site故障，希望其它Site也停止该事务。处理这种情况的技术就称为终止协议。
11、,终结协议与恢复协议的比较 假若一个Site失效 终结协议确定了未失效Site如何处理该失效事件 恢复协议确定失效Site重启动后，进程（协调者，参与者）恢复它的状态的过程 网络分割时 终结协议采取必要的措施来终结在不同网络区间执行的活动事务 当网络重新连接后，恢复协议保证使各个冗余DB相互一致,两阶段提交协议的要点 允许参与者单方面撤销事务，直到做出肯定性的建议 一旦参与者确定了提交或者撤销提议，它不能再更改 当参与者处于就绪状态，它可根据协调者发出的消息的种类，转换为相应的提交或者撤销状态 协调者依据全局提交规则作出全局终结决定 在发生故障的情况下，协调者和参与者可能会进入互相等待的状态，
12、一般采用定时器来解决这种问题,协调者,参与者,2PC-提交,协 调 者,参 与 者,2PC-夭折,集中式2PC,协调者 参与者,I,W,C,A,I,R,C,A,commit-申请 申请-prepare*,no abort*,prepared* commit,commit ACK,申请-prepare prepared,申请-prepare no,abort ACK,F,ACK*,ACK*,标记: 输入消息 输出消息 * = 每一个,当参与者进入“R”状态: 它必定已获得所有资源 它只能根据协调者指令提交或夭折 当所有参与者是在“R”时, 协调者才能进入“C” 状态, 即, 它一定最终能提交,假
13、定撤销2PC和假定提交2PC协议 目的是改善2PC的性能 假定撤销协议中，协调者不必等待参与者的ACK消息，减少了协调者与参与者之间传递消息的数量 假定提交协议中，可以不将Prepare写入Log，减少了Log写入的次数,事务阻断：某个Site上本来可以终结（提交或撤销）的子事务，由于DDBS故障，必须等待到故障恢复（其占有的资源不释放） 阻断协议：提交协议称为阻断协议是指发生某类故障时，使分布式事务可能处于阻断状态 终结协议：允许事务在有故障情况下仍能正确结束,判断2PC协议是终结协议的条件 至少有一个Site已收到结果命令（该Site可以告知其它参与者关于该事务的结果，并由它们来终结该事务
14、） 没有一个参与者收到命令，并且只有协调者Site故障（此时，所有参与者站点都是可工作的，参与者可以选举一个新的协调者，然后继续）,终结协议在协调者和参与者的定时器超时时发挥作用 超时处理技术 协调者超时 在等待状态超时，可以决定“全局撤销” 在撤销状态超时，重发“G-abort” 在提交状态超时，重发“G-commit” 参与者超时（被阻断时出现） 在初始状态超时，单方面Abort 在Ready状态超时，被阻断，等待事务最终处理结果,协调者超时,I,W,C,A,F,commit-申请 申请-prepare*,ack* -,ack* -,no abort*,prepared* commit*,
15、t=timeout,参与者超时,I,R,C,A,申请-prepare prepared,等价于结束状态,_t_ ping,申请-prepare no,commit ack,abort ack,commit ack,abort ack,设计终结协议 假定Pi是超时的参与者（询问Pj），其它Pj按如下响应 Pj处于初始状态，于是单方面Abort，并回送“建议abort”给Pi Pj处于Ready状态，此时不能帮助Pi终结 Pj处于Commit或Abort状态，此时向Pi发送“建议提交”或“建议Abort”,Pi超时，可能有的解释 Pi收到Pj的“建议撤销”回答，此时Pi夭折 Pi收到Pj“建议撤销
16、”回答，但是其它Pj处于Ready状态，此时Pi仍然Abort Pi收到Pj处于Ready状态，此时没有一个参与者有足够的信息恰当地终结事务 Pi收到其他所有的Pj”全局提交”或”全局夭折”消息，Pi可以根据消息终结 Pi收到某些Pj的“全局提交”，而另一些Pj处于Ready状态，Pi可以提交,协调者站点失效 协调者在初始状态失效 发生在协调者初始化提交过程之前 因此，它将在恢复时启动提交过程 协调者在等待状态失效 这时协调者已经发送了“准备”命令 恢复时，协调者将从头开始启动提交过程，再次发送“准备”消息 协调者在提交状态或撤销状态失效 这时，协调者已经把它的决定通知了参与者，并终结了事务 在恢复时，如果它已经收到了所有的确认消息，就不需要做任何事情 否则，就要启动终结协议,参与者站点失效 一个参与者在初始状态失效 在恢复时，该参与者应该单方面撤销事务 一个参与者在就绪状态失效 这时协调者已经收
