假设我有3个节点和两个可能的ArangoDB配置：
或
现在，假设节点1和2发生故障。哪种配置更具弹性？即使运行代理的节点1发生故障，ActiveFailover配置中的从服务器是否可以访问？还是集群配置可以更优雅地处理这种情况，让节点3可以处理读写？
答案 0 :(得分：1)
不幸的是，这两种配置都无法在两个出现故障的节点中幸免。这样做的原因是，没有哪个偏向于一致性而不是可用性的配置将只能在3个节点中的单个节点上继续。这是因为该节点可能是网络拆分的较小部分。如果我们继续使用一个节点，那么我们将面临脑裂的情况，在这种情况下，其他两个节点也将继续存在，并且最终将导致状态不一致。
在ArangoDB中，我们选择了一致性而不是可用性。因此，在其中2个节点发生故障的任何3个节点集合中，尚存的节点将不会继续服务，而要等到至少有一个节点恢复工作。
现在，让我们比较两种配置在一个节点发生故障的情况下的情况：ActiveFailover配置将继续工作，因为两个数据节点（Leader和Follower）中的至少一个将生存，而第三个数据节点仅运行一个代理，他们可以选择一个领导者，并使尚存的数据节点成为领导者。如果only-Agent节点发生故障，那么领导者选举仍然有效，因为其他两个节点实际上也都在运行Agent。但是请注意，如果当前的Leader发生故障，则会发生故障转移，但是由于复制只是异步的，因此某些已提交的数据可能会丢失！
除了具有更对称的设置外，群集的行为基本相同。如果任何一个节点发生故障，其他两个可以继续。如果所有集合至少具有复制因子2，则故障转移可以将每个分片的领导权移至尚存的节点。由于复制是同步的，因此不会丢失任何已提交的数据。与ActiveFailover设置相比，这是群集的优势。但是，请注意，由于同步复制，操作的延迟可能会更高，并且由于并非所有数据都集中在单个节点上，因此某些操作的性能可能会更差，因为我们的数据本地性较低。无论如何，没有免费的午餐，最终必须付费。