问题描述
阅读MongoDB sharding架构的官方文档后，我没有找到为什么你需要一个或三个配置服务器，而不是另一个数字。
After reading the official documentation for the MongoDB sharding architecture I have not found out why you need to have one or three config servers, and not another number.
说：
因此反射：一个服务器相当于一个单点故障，但是有两个服务器，我们有三个相同的行为，对吧？
Hence the reflection: one server is equivalent to a single point of failure, but with two servers we have the same behavior as three, right?
因此，为什么绝对三个服务器，而不只是两个或更多，例如？
So, why absolutely three servers and not only two or more, in example?
因为文档还说：
推荐答案
配置服务器协议
MongoDB 3.0及更早版本仅支持单一类型的配置服务器部署协议，称为传统SCCC（同步群集连接配置）的MongoDB 3.2。 SCCC部署具有1个配置服务器（仅开发）或3个配置服务器（生产）。
Config Server Protocols
MongoDB 3.0 and earlier only support a single type of config server deployment protocol which is referred to as the legacy SCCC (Sync Cluster Connection Configuration) as of MongoDB 3.2. An SCCC deployment has either 1 config server (development only) or 3 config servers (production).
MongoDB 3.2不推荐使用SCCC协议，并支持新的部署类型：作为副本集（CSRS）。 CSRS部署具有与标准副本集相同的限制，其可以具有1个配置服务器（仅开发）或最多50个服务器（生产），如在MongoDB 3.2。
MongoDB 3.2 deprecates the SCCC protocol and supports a new deployment type: Config Servers as Replica Sets (CSRS). A CSRS deployment has the same limits as a standard replica set, which can have 1 config server (development only) or up to 50 servers (production) as at MongoDB 3.2. A minimum of 3 CSRS servers is recommended for high availability in a production deployment, but additional servers may be useful for geographically distributed deployments.
使用SCCC，配置服务器使用协议，其需要来自多个服务器的一致性用于事务。您可以使用单个配置服务器进行测试/开发，但在生产环境中，您应该始终具有3.一个实际的答案为什么你不能在MongoDB中只使用2（或超过3）服务器是MongoDB代码库仅支持用于SCCC配置的1或3个配置服务器。
With SCCC, the config servers are updated using a two-phase commit protocol which requires consensus from multiple servers for a transaction. You can use a single config server for testing/development purposes, but in production usage you should always have 3. A practical answer for why you cannot use only 2 (or more than 3) servers in MongoDB is that the MongoDB code base only supports 1 or 3 config servers for an SCCC configuration.
三个服务器提供比两个服务器更强的一致性保证，例如，备份）在一个配置服务器上，同时仍然有两个服务器可用于您的 mongos 查询。超过三个服务器会增加在所有服务器上提交数据所需的时间。
Three servers provide a stronger guarantee of consistency than two servers, and allows for maintenance activity (for example, backups) on one config server while still having two servers available for your mongos to query. More than three servers would increase the time required to commit data across all servers.
您的分片集群的元数据需要在所有配置服务器上相同， MongoDB sharding实现。元数据包括哪些分片当前持有文档范围的基本细节（aka chunks ）。在SCCC配置中，配置服务器不是复制集，因此，如果一个或多个配置服务器脱机，则配置数据将只读 - 否则数据无法传播到
The metadata for your sharded cluster needs to be identical across all config servers, and is maintained by the MongoDB sharding implementation. The metadata includes the essential details of which shards currently hold ranges of documents (aka chunks). In a SCCC configuration, config servers are not a replica set, so if one or more config servers are offline then the config data will be read only -- otherwise there is no means for the data to propagate to the offline config servers when they are back online.
显然，1个配置服务器不提供冗余或备份。使用2个配置服务器，潜在的故障情况是服务器可用，但服务器上的数据不一致（例如，其中一个服务器有一些数据损坏）。使用3个配置服务器，您可以改进上一个场景：2/3服务器可能是一致的，您可以识别奇数服务器。
Clearly 1 config server provides no redundancy or backup. With 2 config servers, a potential failure scenario is where the servers are available but the data on the servers does not agree (for example, one of the servers had some data corruption). With 3 config servers you can improve on the previous scenario: 2/3 servers might be consistent and you could identify the odd server out.
MongoDB 3.2不赞成使用三个镜像的 mongod 实例来配置服务器，并从3.2配置服务器（默认情况下）部署为副本集。副本集配置服务器必须使用WiredTiger 3.2+存储引擎（或另一个存储引擎，支持新的读隔离语义）。 CSRS还禁止一些非默认的副本集配置选项（例如 arbiterOnly ， buildIndexes 和
MongoDB 3.2 deprecates the use of three mirrored mongod instances for config servers, and starting in 3.2 config servers are (by default) deployed as a replica set. Replica set config servers must use the WiredTiger 3.2+ storage engine (or another storage engine that supports the new readConcern read isolation semantics). CSRS also disallows some non-default replica set configuration options (e.g. arbiterOnly, buildIndexes, and slaveDelay) that are unsuitable for the sharded cluster metadata use case.
CSRS部署提高了配置服务器的一致性和可用性，因为MongoDB可以使用用于分片配置数据的标准副本集读取和写入协议的优点。此外，这允许分片集群具有多于3个配置服务器，因为副本集合可以具有多达50个成员（如在MongoDB 3.2）。
The CSRS deployment improves consistency and availability for config servers, since MongoDB can take advantage of the standard replica set read and write protocols for sharding config data. In addition, this allows a sharded cluster to have more than 3 config servers since a replica set can have up to 50 members (as at MongoDB 3.2).
部署，写可用性取决于维护可以查看副本集的当前主体的成员的仲裁。例如，3节点副本集将需要2个可用成员来维护主节点。可添加其他成员以改进作为正常副本集。 mongos 使用 readConcern 多数 shard集群元数据只有在提交给大多数副本集成员后才能读取，并且最近的 readPreference 用于将请求路由到最近的配置服务器。
With a CSRS deployment, write availability depends on maintaining a quorum of members that can see the current primary for a replica set. For example, a 3-node replica set would require 2 available members to maintain a primary. Additional members can be added for improved fault tolerance, subject to the same election rules as a normal replica set. A readConcern of majority is used by mongos to ensure that sharded cluster metadata can only be read once it is committed to a majority of replica set members and a readPreference of nearest is used to route requests to the nearest config server.
这篇关于为什么MongoDB配置服务器必须只有一个或三个？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！