【问题标题】:Number of arbiters in replication set复制集中的仲裁者数量
【发布时间】:2016-01-14 11:24:15
【问题描述】:

MongoDB tutorial of deploying geographically distributed replica set据说

确保大多数投票成员位于主要设施“站点 A”内。这包括优先级为 0 的成员和仲裁者

我对那里的仲裁者感到困惑,因为在其他地方in documentation我发现

应该在任何副本集中最多配置一个

那么一个副本集中最多可以有多少个仲裁器?如果允许多个仲裁器,那么在副本集中拥有多个仲裁器有什么意义?

【问题讨论】:

    标签: mongodb replication replicaset


    【解决方案1】:

    简介

    “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。

    【讨论】:

    • 回答问题。 :) 假设我们“设置了 3 个数据承载节点”。一名成员宕机(主要)。我们留下了两个次要成员。如果他们都投票给对方,我们将获得平等的票数 - 1 票投给一个,1 票投给其他。他们将无法选举新的初选?
    • @Spookiecookie 不。法定人数由原成员决定。 3 个中的 2 个就足够了。
    • 对于我们的特殊情况,有 2 个仲裁器是有意义的。让我解释一下:我们有 3 个数据中心,但是这 3 个数据中心中的 1 个不适合托管数据承载成员。这就是我们在这个数据中心为每个副本集托管 2 个仲裁器的原因。 replSet 的 3 个数据承载成员托管在另外两个数据中心中(出于弹性原因,我们希望拥有 3 个而不是 2 个数据承载成员)。如果 3 个数据中心中的 1 个因网络分区而宕机或无法访问,replSet 仍然能够选择主节点,因此它仍然是可读写的。
    • @Kay 也许我弄错了,但我看不到在此设置中“出于弹性原因”在一个 DC 中拥有两个数据承载节点的额外好处。如果该 DC 的连接失败,则您在此 DC 中没有仲裁。您将在剩余的数据承载节点上拥有法定人数,但这可以通过在每个符合条件的文档中拥有一个数据承载节点加上一个仲裁器来实现。虽然我看到在一个 DC 中有两个数据承载节点的潜在性能提升和“多数”的写入问题,但这不会使您的设置更具弹性,因为...
    • @Kay 因为如果该 DC 失败,您将确认写入数据可能仍未将其写入剩余的数据承载节点。根据弹性,我宁愿每个 DC 使用两个数据承载节点,一个多数写入关注点和一个仲裁器。
    【解决方案2】:

    我有一个场景,我认为拥有超过 1 个仲裁者是有意义的。

    问题

    我在一个副本集中有 3 个数据承载节点。现在我想在地理上分布我的副本集,以便降低数据中心中断的风险。

    3节点Replicaset,没有解决问题

    • 主数据中心 => 2 个数据承载节点

    • 备份数据中心 => 1 个数据承载节点

    如果该主数据中心已关闭,并且副本集中三个节点中的两个节点将不可用,则备份数据中心中的数据承载节点将无法成为主节点,因为大多数节点不可用。所以 3 节点配置并不能解决数据中心中断的问题。

    5 节点副本集

    • 主数据中心 => 2 个数据承载节点

    • 备份数据中心 => 1 个数据承载节点

    • 第三个数据中心 => 2 个仲裁器

    在这种配置中,我能够维持三个数据中心中的任何一个的中断,并且仍然能够运行。

    显然,更理想的配置是拥有 4 个数据承载节点和 1 个仲裁器。它也会给我备份数据中心的冗余。然而,由于数据承载节点是一个比使用 3 个数据承载节点和 2 个仲裁器的仲裁器更昂贵的提议,因此我很高兴放弃备份数据中心的冗余以节省成本。

    【讨论】:

    • 你是对的,拥有 2 个仲裁者可能是有意义的!我们遇到了一个类似的问题,即拥有 2 个仲裁者是有意义的。我刚刚添加了我的答案。
    【解决方案3】:

    对于我们的特殊情况,有 2 个仲裁器是有意义的。让我解释一下:我们有 3 个数据中心,但是这 3 个数据中心中的 1 个不适合托管数据承载成员。这就是我们在这个数据中心为每个副本集托管 2 个仲裁器的原因。 replSet 的 3 个数据承载成员托管在另外两个数据中心中(出于弹性原因,我们希望拥有 3 个而不是 2 个数据承载成员)。如果 3 个数据中心中的 1 个发生故障或由于网络分区而无法访问,则 replSet 仍然能够选择主节点,因此它仍然是可读写的。仅使用 1 个或 0 个仲裁器是不可能的。因此,2 个仲裁者可能是有意义的。

    让我们看看它的外观。这里有 2 个 replSet,每个 replSet 有 3 个数据承载成员和 2 个仲裁器,分布在 3 个数据中心,而 DC3 是受限数据中心:

    |    |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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-11-24
      • 2013-08-15
      • 2017-10-29
      • 1970-01-01
      • 2015-11-18
      • 1970-01-01
      • 1970-01-01
      • 2017-07-27
      相关资源
      最近更新 更多