复制集中的仲裁者数量
Number of arbiters in replication set
在MongoDB tutorial of deploying geographically distributed replica set中据说
Ensure that a majority of the voting members are within a primary facility, “Site A”. This includes priority 0 members and arbiters.
我对 arbiters 感到困惑，因为在其他地方 in documentation 我发现
There should only be at most one arbiter configured in any replica set.
那么一个副本集中最多可以有多少个仲裁者？如果允许多于一个仲裁者，那么在副本集中有多于一个仲裁者有什么意义？
简介
第一句中 "arbiters" 写成复数是风格原因，不是技术原因。
你真的应该最多有 1 个仲裁者。 IIrc，从技术上讲，您可以拥有更多，但老实说，我从未尝试过。但为了下面的解释，我们假设您可以。
您在这里似乎有点不确定，但正确地假设拥有多个仲裁者没有任何意义。
回顾：仲裁者有什么用？
An arbiter exists to provide a quorum in elections.
取一个有两个数据承载节点的副本集。只要两个实例都启动了，该设置就会运行如预期的那样——它们形成了副本集的 2 个原始成员的 2 票的法定人数。然而，如果一台机器宕机，我们最初只有 2 票中的 1 票，这不是合格的多数，数据承载节点仍然 运行ning 随后将恢复到次要状态，从而无法写入。
为防止出现这种情况，在组合中添加了一个仲裁器。仲裁器无非就是跟踪哪个可用数据承载节点具有最新的可用数据集，并在选举时投票给该成员。因此，对于具有两个数据承载节点的副本集，为了在形成副本集的节点 1 出现故障的情况下获得合格的多数票，我们只需要 1 个仲裁者，因为 2/3 的票数提供了合格的多数票。
超过 2 个数据承载节点的仲裁器
如果我们有一个包含 3 个数据承载节点的副本集，我们就不需要仲裁器，因为我们有 3 个投票成员，如果 1 个成员宕机，其他成员仍然构成举行选举所需的合格多数.
更抽象一点，我们可以通过将副本集中存在的投票数放入以下 "formula"
来确定我们是否需要仲裁器
needArbiter = originalVotes - floor(originalVotes/2) <= originalVotes / 2
如果我们增加一个仲裁器，投票数将是 4：3 个数据承载节点和 1 个仲裁器。一个节点宕机，没问题。第二个节点宕机，副本集将恢复到辅助状态。现在让我们假设两个节点之一是仲裁者——我们将处于次要状态，而数据承载节点只能提供法定人数。我们必须支付并维护一个额外的仲裁器，而不会从中获得任何好处。因此，为了再次提供合格多数，我们需要添加另一个仲裁器（现在是 2 个），除了两个仲裁器可以下线之外没有任何好处。您基本上需要额外的仲裁器来防止您首先不需要的仲裁器的存在成为问题的情况。
现在假设我们有 4 个数据承载节点。由于当其中 2 个出现故障时它们不能形成合格的多数，这与具有 3 个数据承载节点的副本集的情况几乎相同，只是更昂贵。因此，为了允许副本集的 2 个节点同时宕机，我们只需添加一个仲裁器。更多的仲裁者有意义吗？不，甚至比具有两个或 3 个数据承载节点的副本集还要少，因为 2 个数据承载节点 和 仲裁器同时失败的概率是 非常 低。而且你需要的仲裁者数量不均匀。
结论
恕我直言，有 4 个数据承载节点，仲裁器达到了它的用处极限。如果您需要高复制因子，则与数据承载节点相比，使用仲裁器时节省的资金百分比会越来越小。请记住，下一步将是 6 个数据承载节点加上一个仲裁器，因此您节省的成本不到总成本的 1/6。
因此，更一般地说，您拥有的数据承载节点越多（您的 "replication factor" 在 Mongo 术语中越高），拥有额外的仲裁者就越不合理。无论是从技术角度（大多数节点同时失败的概率越来越低）还是从业务角度（具有高复制因子，与整体成本相比，仲裁器节省的资金变得荒谬的小）。
助记词：
The lowest uneven number is 1.
我有一个场景，我认为拥有超过 1 个 Arbiter 是有意义的。
问题
我在一个副本集中有 3 个数据承载节点。现在我想在地理上分布我的副本集，这样我就可以降低数据中心中断的风险。
3节点Replicaset，没有解决问题
主数据中心 => 2 个数据承载节点
备份数据中心=>1个数据承载节点
如果该主数据中心已关闭并且复制集中三个节点中的两个节点不可用，则备份数据中心中的数据承载节点将无法成为主数据中心，因为大多数节点不可用。所以 3 节点配置不能解决数据中心中断的问题。
5个节点副本集
主数据中心 => 2 个数据承载节点
备份数据中心=>1个数据承载节点
第三个数据中心 => 2 个 Arbiters
在此配置中，我能够承受三个数据中心中任何一个的中断，并且仍然能够运行。
显然，更理想的配置是有4个数据承载节点和1个仲裁器。它也会给我备份数据中心的冗余。然而，由于数据承载节点比仲裁器具有 3 个数据承载节点和 2 个仲裁器更有意义，因此我很高兴放弃备份数据中心的冗余以节省成本。
对于我们的特殊情况，有 2 个仲裁器是有意义的。让我解释一下：我们有 3 个数据中心，但这 3 个数据中心中的 1 个不适合托管数据承载成员。这就是为什么我们在这个数据中心为每个副本集托管 2 个仲裁器。 replSet 的 3 个数据承载成员托管在另外两个数据中心（出于弹性原因，我们希望拥有 3 个而不是 2 个数据承载成员）。如果 3 个数据中心中的 1 个出现故障或由于网络分区而无法访问，replSet 仍然能够选择一个主数据中心，因此它仍然是可读可写的。如果只有 1 个或 0 个仲裁器，这是不可能的。因此，2 个仲裁者可能是有意义的。
让我们看看它会是什么样子。这里有2个replSet，每个replSet有3个data bearing member和2个arbiter在3个data center，而DC3是restricted data center:
| |DC1 |DC2 |DC3 |
|----|-----|-----|-----|
|rs1 |m1,m2|m3 |a1,a2|
|rs2 |m1 |m2,m3|a1,a2|
如果一个数据中心出现故障，哪个 replSet 成员将成为主要成员？
- DC1 关闭：
- rs1: m3
- rs2: m2 或 m3
- DC2 故障：
- rs1: m1 或 m2
- rs2: m1
- DC3 故障：
- rs1: m1,m2 或 m3
在MongoDB tutorial of deploying geographically distributed replica set中据说
Ensure that a majority of the voting members are within a primary facility, “Site A”. This includes priority 0 members and arbiters.
我对 arbiters 感到困惑，因为在其他地方 in documentation 我发现
There should only be at most one arbiter configured in any replica set.
那么一个副本集中最多可以有多少个仲裁者？如果允许多于一个仲裁者，那么在副本集中有多于一个仲裁者有什么意义？
简介
第一句中 "arbiters" 写成复数是风格原因，不是技术原因。
你真的应该最多有 1 个仲裁者。 IIrc，从技术上讲，您可以拥有更多，但老实说，我从未尝试过。但为了下面的解释，我们假设您可以。
您在这里似乎有点不确定，但正确地假设拥有多个仲裁者没有任何意义。
回顾：仲裁者有什么用？
An arbiter exists to provide a quorum in elections.
取一个有两个数据承载节点的副本集。只要两个实例都启动了，该设置就会运行如预期的那样——它们形成了副本集的 2 个原始成员的 2 票的法定人数。然而，如果一台机器宕机，我们最初只有 2 票中的 1 票，这不是合格的多数，数据承载节点仍然 运行ning 随后将恢复到次要状态，从而无法写入。
为防止出现这种情况，在组合中添加了一个仲裁器。仲裁器无非就是跟踪哪个可用数据承载节点具有最新的可用数据集，并在选举时投票给该成员。因此，对于具有两个数据承载节点的副本集，为了在形成副本集的节点 1 出现故障的情况下获得合格的多数票，我们只需要 1 个仲裁者，因为 2/3 的票数提供了合格的多数票。
超过 2 个数据承载节点的仲裁器
如果我们有一个包含 3 个数据承载节点的副本集，我们就不需要仲裁器，因为我们有 3 个投票成员，如果 1 个成员宕机，其他成员仍然构成举行选举所需的合格多数.
更抽象一点，我们可以通过将副本集中存在的投票数放入以下 "formula"
来确定我们是否需要仲裁器needArbiter = originalVotes - floor(originalVotes/2) <= originalVotes / 2
如果我们增加一个仲裁器，投票数将是 4：3 个数据承载节点和 1 个仲裁器。一个节点宕机，没问题。第二个节点宕机，副本集将恢复到辅助状态。现在让我们假设两个节点之一是仲裁者——我们将处于次要状态，而数据承载节点只能提供法定人数。我们必须支付并维护一个额外的仲裁器，而不会从中获得任何好处。因此，为了再次提供合格多数，我们需要添加另一个仲裁器（现在是 2 个），除了两个仲裁器可以下线之外没有任何好处。您基本上需要额外的仲裁器来防止您首先不需要的仲裁器的存在成为问题的情况。
现在假设我们有 4 个数据承载节点。由于当其中 2 个出现故障时它们不能形成合格的多数，这与具有 3 个数据承载节点的副本集的情况几乎相同，只是更昂贵。因此，为了允许副本集的 2 个节点同时宕机，我们只需添加一个仲裁器。更多的仲裁者有意义吗？不，甚至比具有两个或 3 个数据承载节点的副本集还要少，因为 2 个数据承载节点 和 仲裁器同时失败的概率是 非常 低。而且你需要的仲裁者数量不均匀。
结论
恕我直言，有 4 个数据承载节点，仲裁器达到了它的用处极限。如果您需要高复制因子，则与数据承载节点相比，使用仲裁器时节省的资金百分比会越来越小。请记住，下一步将是 6 个数据承载节点加上一个仲裁器，因此您节省的成本不到总成本的 1/6。
因此，更一般地说，您拥有的数据承载节点越多（您的 "replication factor" 在 Mongo 术语中越高），拥有额外的仲裁者就越不合理。无论是从技术角度（大多数节点同时失败的概率越来越低）还是从业务角度（具有高复制因子，与整体成本相比，仲裁器节省的资金变得荒谬的小）。
助记词：
The lowest uneven number is 1.
我有一个场景，我认为拥有超过 1 个 Arbiter 是有意义的。
问题
我在一个副本集中有 3 个数据承载节点。现在我想在地理上分布我的副本集，这样我就可以降低数据中心中断的风险。
3节点Replicaset，没有解决问题
主数据中心 => 2 个数据承载节点
备份数据中心=>1个数据承载节点
如果该主数据中心已关闭并且复制集中三个节点中的两个节点不可用，则备份数据中心中的数据承载节点将无法成为主数据中心，因为大多数节点不可用。所以 3 节点配置不能解决数据中心中断的问题。
5个节点副本集
主数据中心 => 2 个数据承载节点
备份数据中心=>1个数据承载节点
第三个数据中心 => 2 个 Arbiters
在此配置中，我能够承受三个数据中心中任何一个的中断，并且仍然能够运行。
显然，更理想的配置是有4个数据承载节点和1个仲裁器。它也会给我备份数据中心的冗余。然而，由于数据承载节点比仲裁器具有 3 个数据承载节点和 2 个仲裁器更有意义，因此我很高兴放弃备份数据中心的冗余以节省成本。
对于我们的特殊情况，有 2 个仲裁器是有意义的。让我解释一下：我们有 3 个数据中心，但这 3 个数据中心中的 1 个不适合托管数据承载成员。这就是为什么我们在这个数据中心为每个副本集托管 2 个仲裁器。 replSet 的 3 个数据承载成员托管在另外两个数据中心（出于弹性原因，我们希望拥有 3 个而不是 2 个数据承载成员）。如果 3 个数据中心中的 1 个出现故障或由于网络分区而无法访问，replSet 仍然能够选择一个主数据中心，因此它仍然是可读可写的。如果只有 1 个或 0 个仲裁器，这是不可能的。因此，2 个仲裁者可能是有意义的。
让我们看看它会是什么样子。这里有2个replSet，每个replSet有3个data bearing member和2个arbiter在3个data center，而DC3是restricted data center:
| |DC1 |DC2 |DC3 |
|----|-----|-----|-----|
|rs1 |m1,m2|m3 |a1,a2|
|rs2 |m1 |m2,m3|a1,a2|
如果一个数据中心出现故障，哪个 replSet 成员将成为主要成员？
- DC1 关闭：
- rs1: m3
- rs2: m2 或 m3
- DC2 故障：
- rs1: m1 或 m2
- rs2: m1
- DC3 故障：
- rs1: m1,m2 或 m3