• 模块化
– 系统的每个组件都设计为具有定义很好的输入/输出 接口的模块 – 模块化可以把故障隔离在单一的组件中
• 系统实现
– 故障-停止模块（fail-stop module) – 进程对（Process pairs)
2 分布式数据库系统的故障原因和容错技术
2.2 基本容错方法和技术
• 故障-停止模块
徐俊刚
（xujg@)
2009年2月——2009年6月
第6章 分布式数据库中的可靠性
1. 分布式数据库的可靠性的概念及其度量 2. 分布式数据库系统的故障原因和容错技术 3. 分布式数据库的可靠性协议 4. 网络分割和提交协议 5. 不一致性监测和解决方法
1 分布式数据库可靠性概念及其度量
2PC-提交
PREPARE
协调者
COMMIT
ACK
参与者
PREPARED
2PC-夭折
PREPARE
协 调 者
NO ABORT
ACK
参 与 者
3 分布式数据库的可靠性协议
3.4 两阶段提交协议的演变
协调者
参与者
I
commit-申请 申请-prepare*
I
no abort*
申请-prepare prepared
• 两者关系
– 通常认为构建可用性的系统比可靠性的系统容易 – 两者是统一的，可靠性高的系统可用性自然是好的 – 两者又是矛盾的，增加错误风险的情况下，可提高可用性;采 用太谨慎的策略会降低可用性
1 分布式数据库可靠性概念及其度量
1.1 分布式数据库可靠性概念
已知
例:
Site1 x1 Lock x1 2PC Ready
• 可靠性协议组成
– 包括提交、终结、恢复协议
– 提交和恢复协议详细说明提交命令和恢复命令是如何 执行的 – 终结协议是分布式系统特有的协议。在执行一个分布 式事务时，若一个Site故障，希望其它Site也停止该事 务。处理这种情况的技术就称为终止协议。
3 分布式数据库的可靠性协议
3.3 分布式可靠性协议
环境
系统
刺激
component1
component2 响应
component3
• 系统规范说明（Specification） 系统提供的对所有可能 的刺激将产生的响应行为必须遵循的说明
2 分布式数据库系统的故障原因和容错技术
2.1 系统失败的原因
• 故障 – 任何偏离规范说明的行为 • 软故障和硬故障 – 软故障包括间歇性（intermittent）和瞬变性 （transient）故障，通过重启动来修复 – 硬故障指永久性故障, 错误设计等 • 软件和硬件故障
– 不断地对自身进行检测，当检测到一个故障 时，就自动停止。 – 优点是缩短了故障检测的潜伏期。
time
正常
停止
恢复
稳定存储 ok
正常
易失存储丢失
2 分布式数据库系统的故障原因和容错技术
2.2 基本容错方法和技术
• 进程对（Process pairs)
– 通过软件模块的双工来实现容错。两个进程，一个是 主进程，一个是备份，它们同时提供同样的服务，主 进程与备份进程都是基于故障-停止模块实现。 – 分类方式（根据主进程和备份进程之间的通信方式）
申请-prepare no
W
prepared* commit ACK*
A
commit ACK
R
abort ACK
A
C
ACK*
F
C
标记: * = 每一个 输入消息 输出消息
集中式2PC
3 分布式数据库的可靠性协议
3.4 两阶段提交协议的演变
• 当参与者进入“R”状态:
– 它必定已获得所有资源 – 它只能根据协调者指令提交或夭折
3 分布式数据库的可靠性协议
3.3 分布式可靠性协议
• 目的
– 维持在多个数据库上执行的事务的原子性和 持久性
• 原语
– Begin_Transaction – read, write, – Abort, commit
• 命令执行与局部协议类似
3 分布式数据库的可靠性协议
3.3 分布式可靠性协议
• 指数型失败和修复的概率的系统可用性
– A=MTBF/(MTBF+MTTR)
• 可用性系统
– 5个9（99.999%）常用来描述可用性系统 – 但是可用性系统要求的成本比较高 – 具体设计时要综合用户两方面的要求
2 分布式数据库系统的故障原因和容错技术
2.1 系统失败的原因 • 系统（System） 是由一组组件构成的一种机制，这些 组件通过响应来自某个环境的具有可识别行为模式的 刺激而相互作用。
Site2 x2 Lock x2
• • • • •
x1和x2是x的副本 事务T是更新x的事务 Site 1是协调站点 Site 1是事务T原发站点 遵守两阶段提交协议
Site1也Ready 故Commit 故障出现 Site 2 等待
此时Site 2有两种可能:
a> 以正确性为标准，x2则 等待, 并Lock 2, 直到故障恢 复。提高了可靠性，但牺牲 了可用性。 b> 引入不一致性的风险下, 尽量提高可用性，解锁x2, 其它事务可以使用它的值。
• 终结协议与恢复协议的比较
– 假若一个Site失效
• 终结协议确定了未失效Site如何处理该失效事件 • 恢复协议确定失效Site重启动后，进程（协调者，参与者）恢 复它的状态的过程
– 网络分割时
• 终结协议采取必要的措施来终结在不同网络区间执行的活动事 务 • 当网络重新连接后，恢复协议保证使各个冗余DB相互一致
2 分布式数据库系统的故障原因和容错技术
2.1 系统失败的原因
• 软故障 占90%以上并且该比例稳定
– 67年， 美空军指出计算机中电子故障80%是间 歇性的
– 67年，IBM 指出 90%故障是间歇性的 – 80年，研究指出软故障明显高于硬故障 – 87年，Gray指出 大部分软件故障是瞬变性故障
2 分布式数据库系统的故障原因和容错技术
2.1 系统失败的原因
• 审查不同计算机系统中出错的统计数据
– IBM/XA 的OS 可靠性报告 57%是硬件, 12% 软件, 14%操作, 7% 环境（斯坦福 线性加速器SLAC）
– Tandem计算机 18%硬件 25% 软件 25%维护 17%操作, 14%环境 – AT&T 5ESS数字交换机 17.5%操作 32.3%硬件, 44.3%软件,
• 软件故障
– 通信或DB的原因是产生软件故障的主要原因.
– 代码中的Bug, 曾有报告指出, 1000条指令中, 0.25-10 个BUG
永久性 故障
永久性 错误
错误的 设计
不稳定 或者 临界的 组件 不稳定的 外部环境 操作者 的过失
系
间歇性 错误 统
失 瞬变的 错误
败
系统失败的原因
2 分布式数据库系统的故障原因和容错技术
• 当所有参与者是在“R”时, 协调者才能进 入“C” 状态, 即, 它一定最终能提交
3 分布式数据库的可靠性协议
3.4 两阶段提交协议的演变
• 假定撤销2PC和假定提交2PC协议
– 目的是改善2PC的性能 – 假定撤销协议中，协调者不必等待参与者的 ACK消息，减少了协调者与参与者之间传递 消息的数量 – 假定提交协议中，可以不将Prepare写入Log， 减少了Log写入的次数
• • • • • 锁定-步进方式 自动检查点设置方式 状态检查点设置方式 Delta检查点设置方式 持久进程对
3 分布式数据库的可靠性协议
3.1 分布式数据库系统故障
• • • •
事务故障 系统故障 介质故障 通信故障
站点故障
3 分布式数据库的可靠性协议
3.2 局部可靠性协议
• 局部恢复管理器 (LRM)
Site 1 正常结束
1 分布式数据库可靠性概念及其度量
1.2 平均故障间隔时间和平均修复时间 • 平均故障间隔时间
– 指在可以自我修复的系统中相继失败之间的期望时间 – 通过可靠性函数来计算MTBF=∫0∞R(t)dt – MTBF与系统失败的概率有直接的关系
• 平均修复时间
– 是指修复一个系统所需要的期望时间，MTTR – 它与失败概率有关
2.2 基本容错方法和技术
• 容错
– 设计一种使系统识别出可能会发生的错误的方法。 在系统中建立一种机制，使错误在造成系统故障之 前就会被检测出来，并能被清除或得到补偿。
• 错误预防
– 保证所实现的系统不包含任何错误 – 错误回避：保证系统不会带入错误的技术（详细的 设计方法学和质量控制） – 错误清除：清查那些在使用了错误回避技术路线后 还残留在系统中的错误，并清除它们（需要大量的 测试和证实过程）
2 分布式数据库系统的故障原因和容
– 潜伏的故障：故障发生一段时间后才被检测出 来 – 错误潜伏期：从故障发生到被检测出来的时间 – 平均检测时间(MTTD)：平均错误潜伏时间 – 平均修复时间(MTTR)：修复一个失败的系统所 需要的期望时间 – 平均故障间隔时间(MTBF)：在可以自我修复的 系统中相继的失败之间的期望时间, 由经验或 从可靠性函数计算
– 每个站点一个 – 维护局部事务的原子性和持久性
• 体系结构
– – – – – – 数据库存储在稳定存储器中 存储和访问稳定数据库的单位是页面 缓冲区中的数据库称作易失数据库 LRM仅仅在易失数据库上执行事务操作 对数据库的访问都要经由数据库缓冲区管理器 Flush(冲洗) 实现将数据库缓冲区页对稳定DB的强 迫写
3 分布式数据库的可靠性协议