cluster-computing - 为什么在 Service Fabric 中使 Min 和 Target Replica Size 相同？

Question

这个问题是专门针对 Service Fabric 的，但是这个概念超出了这个集群系统的范围，所以在没有 SF 经验的情况下可以随意参与。

我试图了解将 MinReplicaSetSize 和 TargetReplicaSetSize 设置为有状态服务的相同或不同数字的优缺点。

假设您有 10 个分区和 3 个副本。这意味着每个分区将有 3 个副本（1 个主副本和 2 个辅助副本）。假设您有一些 Collection 分布在这 10 个分区中。有2种情况需要考虑：

MinReplica 和 TargetReplica = 3

在某些分区上，主副本失败。其中一个从属被提升为主要。由于 Replica count = 2 < MinReplica 然后写入此分区失败/停止，直到新的辅助节点被假脱机并与其他辅助节点同步，因此计数再次为 3。明显的缺点是停止写入。

MinReplica = 2 和 TargetReplica = 3

在某些分区上，主副本失败。其中一个从属被提升为主要。由于 MinReplica 计数仍然是安全的，因此继续写入新主节点并更新 1 个左辅助节点。当这种情况发生时，另一个辅助节点被假脱机，然后必须在写入继续时提高速度。那么缺点是什么？

在新的辅助节点跟上速度之前，新的主节点是否有可能失败，辅助节点提升为主节点并且也失败；因此丢失已提交的数据？这是缺点吗？在 MinReplica=3 / TargetReplica=4 的情况下，即使这样也不会发生。

我问是因为我通常将这些视为相等的数字并开始考虑它。

标签： cluster-computingazure-service-fabricdistributed-computingdistributed-system

Answer 1

此语句“在某些分区上，主副本发生故障。其中一个辅助副本被提升为主副本。由于副本计数 = 2 < MinReplica 然后写入此分区失败/暂停，直到新的辅助副本被假脱机并与其他副本一起加速这样计数又是 3。 " 是不正确的。

为了使写入成功，操作必须在 N 个副本中的多数 (N/2)+1 上成功。拥有三个副本，意味着仲裁大小为 2。如果 2 次写入成功，则写入操作成功。将其更改为 2 不会影响仲裁。法定人数的大小是从MinReplicaSetSize大小派生的。将其更改为5意味着仲裁大小为3，然后您关于丢失 1 个副本的声明将变得有效。

另外，请注意，这是副本集上的MinReplicaSetSize“视图”：

MinReplicaSetSize 定义了视图中的最小副本数，例如，如果 TargetReplicaSetSize 为 5，MinReplicaSetSize 为 3，那么即使有 3 个并发故障 [它] 在其副本集的视图中仍然有 3 个副本。