第6章_分布式数据库中的可靠性_2.pptVIP

6.5.1 决定网络的状态 网络 站点 K-3 UP 站点 K-2 DOWN 站点 K-1 站点 K UP DOWN (状态) 站点K控制站点K-3, 即它检查来自K-3的I-am-up报文是否到达， 站点K负责发现站点K-1和K-2从不工作到工作的恢复， 上图中K-1和K-2不一定是有故障, 它们可能在分割的另一组中， 图反映了站点K和K-3的网络视图 网络上站点的状态 6.5.1 决定网络的状态 广播新的状态 监视功能每次检测出一个状态变化, 就激活此广播功能 此功能的目的是广播新的状态表，使同一组的全部站点具有相同的状态表 此功能可由若干站点并行激活, 需要某种机构来控制冲突 状态表的每个新的版本附加一全局唯一的时间戳 在I-am-up报文中包含当前状态表的版本号 启动新状态表广播的站点首先执行一次同步以获得一时间戳，然后发送状态表给已回答的所有站点 6.5.2 不一致性的检测和解决方法概念 需求 处理故障的策略有可能牺牲正确性来提高可用性，因此接受了不一致性的风险 在这种情况下，监测这些不一致性，并尽可能地加以解决是很有用的 概念 需要首先发现哪些数据部分已经不一致（不一致性检测） 然后根据发生的情况，给这些部分赋予一个最合理的值（不一致性的解法） 6.5.3 不一致性的检测 提出问题 假设网络分割期间, 在两个或多个站点组中已执行了若干事务, 可能对同一数据片断的不同副本进行了独立更新 检测方法 一种比较自然的方法 比较各副本的内容, 检查其是否相同，但是这种方法不仅效率低，一般也是不正确的。 6.5.3 不一致性的检测 检测方法 采用版本号 允许对数据项操作的站点的副本是主副本, 其它是孤立或隔离的副本 正常工作期间, 全部副本都是主副本, 并且互相一致, 每份副本维持一个原版号和一个当前版本号 网络分割时, 每个孤立副本的原版本号被置为当前版本号值, 并且, 直到分割修复为止, 此原版号不会改变 6.5.3 不一致性的检测 例子 已知前提 数据项x的副本x1, x2, x3 存储在三个不同站点 V1, V2, V3分别是x1, x2, x3的版本号 初始时, 三份副本一致, 所以有: 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未曾修改 6.5.3 不一致性的检测 假设分割时, 只更新x3, 版本号为 V1=(0, 2) V2 =(0, 2) V3=(2, 3) 此时若没有其它孤立副本, 则可以用x3的更新施加到主副本, 但若还有x4，V4=(2,3)， 则即使x3与x4版本号相同也不能说其是一致的 若主副本与孤立副本都更新过, 版本号为 V1=(0, 3) V2 =(0, 3) V3=(2, 3) 那么，此孤立副本的原版本号和当前版本号是不同的，而且此孤立副本的原版本号也与主副本的当前版本号不同 6.5.4 不一致性的解决方法 网络分割已修复和不一致性已检测出来后，必须给同一数据项的全部拷贝赋予一共同的值，不一致性解法的问题是如何决定这个值 不一致的解决办法与应用相关 航空订票系统 暂停订票, 收集旅客请求, 网络修复后再集中订票 赋予各订票点的订票数小于总数 6.5.5 检查点和冷启动 在分布式数据库中，冷启动是比较罕见的 一般来说，当网络中的一个站点丢失了运行记录信息之后，就要求冷启动 分布式数据库冷启动中, 一个站点要建立一早期状态, 那么所有其它站点也必须建立起与该站点一致的早期状态, 这意味着此恢复过程本质上是全局的, 要影响到数据库的全部站点, 虽然引起冷启动的故障一般讲是本地的. 以前的一致性状态是由检查点来标志的 6.5.5 检查点和冷启动 一致的全局状态C的两个特征 对于每个事务T, C包含了T在任何站点的全部事务所执行的更新, 或者它不包含它们中的任何一个。 如果一事务T被包含在C中, 则按串行化次序, 在T前面的全部冲突事务也包含在C中 重构全局一致状态的最简单办法是使用 本地转储 本地的运行纪录 全局的检查点 6.5.5 检查点和冷启动 如果有全局检查点, 则重构就相对容易. 首先在故障站点处决定认为是安全的最近的一个本地检查点,这就确定了必须重构的较早的全局状态 然后请求所有其它站点重新建立相对应的本地检查点的本地状态 存在的问题 只有一个站点把一“写检查点”报文广播给所有其它