![](https://csdnimg.cn/release/download_crawler_static/88804991/bg6.jpg)
ACM Transactions on Storage,Vol.号143、第二十一条。出版日期:2018年10月
假设
S2
是领导者。当
S1
读取其日志时,它检测到损坏;然而,
S1
截断其日志,丢失损坏的条目
和所有后续条目(图2(ii))。与此同时,
S2
(领导者)和
S3
崩溃.
S1
、
S4
和
S5
形成多数,并
选举
S1
为领导者。现在,系统不知道已提交的条目1、2和3,从而导致
静默数据丢失
。系统
还提交新条目x、y和z来代替1、2和3(图2(iii))。最后,当S
2
和S
3
恢复时,它们遵循S
1
总之,尽管故障节点检测到损坏,但它会截断其日志,从而丢失本地数据。当这个
节点与其他落后的节点一起形成多数时,数据会悄悄地丢失,从而违反安全性。我们
在
ZooKeeper
和
LogCabin
中发现了这种安全违规行为
此外,Truncate遭受
低效率
的恢复。例如,在图1(i)中,
S1
在故障后截断其现在要修复
S
1
ZooKeeper和LogCabin都存在恢复缓慢的问题。
删除重建。另一个常用的操作是手动删除故障节点上的所有数据并重新启动该节点。不幸
的是,与Truncate类似,DeleteRebuild可能会违反安全性:数据被删除的节点可能会与落后
的节点一起形成多数,从而导致无声的数据丢失。令人惊讶的是,管理员经常使用这种方
法,希望通过从其他节点获取数据来“简单地修复”故障节点DeleteRebuild也遭受类似于
Truncate的恢复缓慢问题。
MarkNonVoting. 在Google基于Paxos的系统中使用的这种方法中,故障节点删除其故障
上的所有数据,并将自己标记为无投票权的成员;节点不参与选举,直到它观察到一轮共识
并从其他节点重建其数据。通过将故障节点标记为无表决,可以避免图2中的安全违规。
然而,
MarkNonVoting
有时会违反安全性,正如先前的工作所指出的那样[74]。不安全的
根本原因是损坏的节点删除其所有状态,包括给予领导者的承诺
2
。一旦一个错误节点失去
了给新领导者的承诺,它就可以接受来自旧领导者的条目然而,新领导者仍然相信它有来
自故障节点的承诺,因此可以覆盖先前由旧领导者提交的条目
此外,这种方法的缺点是不可用。例如,当只有大多数节点存活时,单个故障可能导致
不可用,因为故障节点不能投票;其他节点现在不能选举领导者。
重新配置在这种方法中,删除一个故障节点并添加一个新节点。但是,要更改配置,配置
条目需要由多数人提交。因此,系统在许多情况下仍然不可用(例如,当大多数节点存活
但一个节点的数据被破坏时)。虽然在实际系统中不使用
重新配置
来解决存储故障,但先
前的研究已经提出了[16,46]。
BFT。一种极端的方法是使用拜占庭容错算法,该算法在理论上应该容忍存储故障。然
而,
BFT
在实际存储系统中的使用成本很高;具体而言,
BFT
只能实现容错协议所能实现的
吞吐量的一半[22]。此外,
BFT
需要3
个
f
+
1节点来容忍f个故障[1],因此在图1中的大多数
场景中保持不可用。
[
2
]
在
Paxos
中,对编号为
p
的提议的承诺是由跟随者(接受者)向领导者(提议者)做出的保证,保证它将来
不会接受编号小于
p
的提议