简介
“arbiters”在第一句中写成复数是有风格的原因,而不是技术原因。
你真的应该最多有 1 个仲裁者。 Iirc,从技术上讲,你可以拥有更多,但老实说,我从未尝试过。但是为了下面的解释,我们假设你可以。
您在这里似乎有点不确定,但正确地假设拥有多个仲裁者没有任何意义。
回顾:仲裁员有什么用?
存在仲裁者以提供选举中的法定人数。
获取具有两个数据承载节点的副本集。只要两个实例都启动,该设置就会按预期运行——它们构成了副本集的 2 个原始成员的 2 票的法定人数。但是,如果一台机器宕机了,我们原来只有 1 票 2 票,这不是合格的多数,并且仍在运行的数据承载节点随后将恢复到辅助状态,从而无法写入。
为了防止这种情况发生,在混合中添加了一个仲裁器。仲裁者只是跟踪哪些可用的数据承载节点拥有最新的可用数据集,并在选举时为该成员投票。因此,对于具有两个数据承载节点的副本集,为了在形成副本集的节点中的 1 个出现故障的情况下获得合格多数票,我们只需要 1 个仲裁者,因为 2/3 票提供了合格多数。
超过 2 个数据承载节点的仲裁器
如果我们有一个包含 3 个数据承载节点的副本集,我们就不需要仲裁器,因为我们有 3 个投票成员,如果有 1 个成员宕机,其他成员仍然构成举行选举所需的合格多数。
更抽象一点,我们可以通过将副本集中存在的投票数代入以下“公式”来确定是否需要仲裁器
needArbiter = originalVotes - floor(originalVotes/2) <= originalVotes / 2
如果我们增加一个仲裁器,投票数将是 4:3 个数据承载节点和 1 个仲裁器。一个节点宕机,没问题。第二个节点关闭,副本集将恢复到辅助状态。现在让我们假设两个节点之一是仲裁器——我们将处于辅助状态,而数据承载节点只能提供仲裁。我们必须支付并维护一个额外的仲裁器,而不会从中获得任何收益。因此,为了再次提供合格的多数,我们需要再添加一个仲裁器(现在是 2 个),除了两个仲裁器可以倒下之外没有任何好处。您基本上需要额外的仲裁器来防止出现您最初不需要的仲裁器成为问题的情况。
现在假设我们有 4 个数据承载节点。由于当其中 2 个宕机时它们无法形成合格多数,这与具有 3 个数据承载节点的副本集的情况几乎相同,只是成本更高。因此,为了允许副本集的 2 个节点同时关闭,我们只需添加一个仲裁器。更多的仲裁者有意义吗?不,甚至比具有两个或 3 个数据承载节点的副本集还要少,因为 2 个数据承载节点 和 仲裁器同时失败的概率是 非常低的。而且你需要的仲裁者数量是奇数。
结论
恕我直言,有 4 个数据承载节点,仲裁器达到了其有用性的极限。如果您需要高复制因子,那么与数据承载节点相比,使用仲裁器节省的资金百分比会越来越小。请记住,下一步将是 6 个数据承载节点和一个仲裁器,因此您节省的成本不到总成本的 1/6。
所以更一般地说,您拥有的数据承载节点越多(Mongo 术语中的“复制因子”越高),拥有额外的仲裁器就越不合理。无论是从技术角度(大多数节点同时发生故障的概率越来越低)还是从业务角度(复制因子高,与整体成本相比,仲裁器节省的资金变得越来越低)小得离谱)。
助记符:
最小的奇数是1。