为什么MongoDB文档建议/坚持特定的副本集优先级配置 [英] Why do MongoDB docs recommend/insist on specific replica set priority configurations

问题描述

http://docs.mongodb.org/manual / tutorial / deploy-geographically-distributed-replica-set /

我特别好奇为什么他们通常想要非主要数据中的副本中心将选举的优先级设置为0？如果一个数据中心发生故障，我希望能够故障转移到另一个数据中心的副本中的一个。该文档似乎坚持认为，与主数据库不同的数据中心中的辅助副本的优先级应为0，因此在主数据中心发生故障的情况下不具有主状态的资格。是我可以忽略我的需要吗？

I'm particularly curious as to why they generally want replicas in the non-primary data centre to be priority 0 for elections? If one data centre goes down, I want to be able to failover to (one of) the replica(s) in another data centre. The documentation seems to insist that secondary replicas in a different data centre from the primary should be priority 0, and thusn ineligible for primary status in case of a failure of the "main" data centre. Is this something I can disregard for my needs?

推荐答案

我认为您在这里没有重点。如果您将标准配置保留在主要数据中心中，则该数据中心处于关闭状态，即使您将优先级设置为1，您也将无法选择新的主要数据中心。

I think you are missing the point here. If you keep the standard configuration with a majority in the primary data center you wont be able to elect new primary if this data center is down even if you set priority to 1.

让我们假设您具有这样的配置：

Lets assume you have configuration like this:

• 位置A：2个成员，优先级1，仲裁者


• 位置B：1个成员，优先级为0


• 位置C：1个成员，优先级为0

场景：

1. 位置A向下。
   
   
   
   • 即使您将数据中心B和C的成员的优先级设置为1，您也不会以多数选举新的主要成员。
   
   

• rs正常工作

• rs按预期工作

• rs可以正常工作，只要我们可以与B或C进行通信

• rs按预期工作我们可以与B和C进行长期沟通

• 这是唯一有问题的情况。我们有3个投票成员，但没有一个可以成为主要成员。

对于较大的群集，其工作原理类似。

You check that it work similarly for larger clusters.

这篇关于为什么MongoDB文档建议/坚持特定的副本集优先级配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！