第5章 分布式数据库中的事务管理与恢复.ppt

网络分割 站点假设分成两组：协调者组和参与者组。 一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同1.a, 1.b。 从参与者组看是协调者站点故障，动作如1.c, 1.d。 3.2 两阶段提交协议和故障恢复 3 两阶段提交协议 初始 写begin_commit到日志 等待 有要求撤消的？ 写commit到日志 提交 写Complete到日志 初始 准备提交？ 写ready到日志 就绪 消息类型？ 写abort到日志 写commit到日志 提交 撤消 撤消 写abort到日志 写abort到日志 协调者 参与者 no no abort commit 2. b 准备 2.a撤消 2.a 提交 2.c全局撤消 全局提交 ACK ACK 1.c 1.d 1.e 1.a 1.b 2.d 多站点数据更新 方法 ：站点A上有事务T对X更新, X在B1,…Bn和C1,…Cm上有副本, 则也要对这些副本更新 问题 多个站点同时更新不现实(每一个站点某一时刻与站点A连通的概率小于1） 对未连通站点上的副本更新增多时出错, 更新的顺序也不一定是连通顺序 4.1 多站点数据更新 4 分布式数据库中的数据更新 4.1 多站点数据更新 4 分布式数据库中的数据更新 站点A 要更新X 站点B1 站点B2 站点Bn 站点C1 站点C2 站点Cm 说明： (1) X在B1,B2,…,Bn 和C1,C2,…,Cm上 都有副本； (2)但只有站点 B1,B2,…,Bn 与站点A连通而站点 C1,C2,…,Cm 与站 点A暂时未连通。 主文本更新 思想：指定主副本, 修改只对主副本进行, 修改辅助副本时, 也按在主副本上执行的更新顺序执行 问题 修改传播必须在短时间内完成, 否则将获得“过时”数据 主副本不可用, 引得其他副本也不可用 4.2 主文本更新 4 分布式数据库中的数据更新 4.2 主文本更新 4 分布式数据库中的数据更新 网络 站点A X主 文本 站点B2 X辅 文本 站点B1 X辅 文本 站点B3 X辅 文本 站点B5 X辅 文本 站点B4 X辅 文本 T1 T2 未连通 T1在T2之前 移动主文本法 若初次更新在辅文本上进行，然后再把更新引向该数据的主站点 如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新 待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新 如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新 移动文本法的问题 网络分割成很多部分时，更新处理会不一致 网络分割成W1,W2，W1中X更新为R, W2中X更新为S,网络连通时，使用R还是S来恢复X呢？ 4.2 主文本更新 4 分布式数据库中的数据更新 业务规则约束 有效性约束: 域约束，数据项的取值范围 数据依赖约束: 实体完整性和引用完整性 例子 取现金时 一个账户的存款余额必须大于零 转账时 一个账户的存款余额必须大于零. 事务结束时,两账户中存款总和, 必须与事务开始时两账户存款之和相同 定期利息计算 事务执行后, 所有账户存款之和比事务开始前各账户存款总和大于10%（假定利息是总额的10%） 5.1 业务规则的一致性 5 分布式事务增强数据库一致性 业务规则要强制执行 用户编写的事务中 由DBMS事务优化器产生的事务中 在产生的分布式执行方案中，要编入业务规则的强制条件 或者从数据字典中获取相关的业务规则，并在生产分布式事务的时候使用它 多数商用分布式DBMS的事务优化器，只加入少数几类业务规则，为了补救这种不足，需要 程序员必须编写加进业务规则的分布式事务 必须定期对数据库进行扫描，监测不一致的数据，并予以清除 找出那些没有实施的，不能由事务优化器加上的强行业务规则 5.1 业务规则的一致性 5 分布式事务增强数据库一致性 5.2 冗余数据的一致性 5 分布式事务增强数据库一致性 分布式数据库冗余设计的理由 提高系统的可用性和可靠性 如果用户由于某种原因无法访问某个成员数据库，它可以访问另外一个成员数据库上的相同片断 提高“读”事务的本地性 降低通信成本 例如，一个片断存放在该事务的原发站点中，那么就免除了传输请求和返回结果的花费 但是，如果事务包含对片断的更新，则其所有副本也必须做同样的更新，这时反而增加而不是降低通信成本 例子 site1 site2 T1: Read(x) x=x*1.1 write(x) T2: Read(x) x=x-20 write (x) 设数据x在两个站点都有副本.