副本集的体系结构会影响副本集的容量和功能。本文档提供了副本集部署的策略，并介绍了常见的体系结构。
生产系统的标准副本集部署是一个三成员副本集。这些集提供冗余和容错能力。尽可能避免复杂性，但应由您的应用程序要求决定体系结构。
根据这些策略在副本集中添加成员。
确保副本集的投票成员数为奇数。一个副本集最多可以有7个投票成员。如果您 的表决成员数为偶数，请部署另一个具有数据表决权的成员，或者，如果约束禁止另一个有数据表决权的成员，请部署一个 仲裁程序。
一个仲裁者不存储数据的副本，并需要更少的资源。结果，您可能在应用程序服务器或其他共享进程上运行仲裁程序。如果没有数据副本，则有可能将仲裁器放置在您不会放置副本集其他成员的环境中。请查阅您的安全策略。
对于以下版本的MongoDB，
与带有仲裁器的副本集相比（在MongoDB 4.0+中不再支持）pv1，w:1回滚的可能性增加了pv0：
请参见副本集协议版本。
警告
通常，避免每个副本集部署多个仲裁器。
副本集的容错能力是可以变得不可用并仍在集合中保留足够数量的成员来选择主要成员的成员数。换句话说，它是集合中majority的成员数量与选举主要成员所需的投票成员数量之差。没有主数据库，副本集不能接受写操作。容错是副本集大小的影响，但关系不是直接的。见下表：
| 会员人数 | 选出新小学的多数 | 容错能力 |
|---|---|---|
| 3 | 2 | 1个 |
| 4 | 3 | 1个 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
将成员添加到副本集并不总是会提高容错能力。但是，在这些情况下，其他成员可以为专用功能（如备份或报告）提供支持。
从4.2.1版开始，rs.status()返回
majorityVoteCount副本集。
在读取流量非常高的部署中，可以通过将读取分发给辅助成员来提高读取吞吐量。随着部署的增长，将成员添加或移动到备用数据中心以提高冗余性和可用性。
注意
在两个数据中心之间分布副本集成员可提供优于单个数据中心的好处。在两个数据中心分布中，
如果可能，请在至少三个数据中心中分配成员。对于配置服务器副本集（CSRS），最佳实践是分布在三个（或更多，取决于成员的数量）中心中。如果第三个数据中心的成本过高，则一种分配可能性是，在公司政策允许的情况下，在两个数据中心之间平均分配数据承载成员，并将剩余成员存储在云中。
始终确保主要设施能够选出主要设施。
副本集的现有成员必须具有备用容量以支持添加新成员。始终在当前需求饱和集合容量之前添加新成员。
为了在数据中心发生故障时保护您的数据，请在备用数据中心中至少保留一个成员。如果可能，请使用奇数个数据中心，并选择成员分布，以最大程度地保证即使丢失数据中心，其余副本集成员也可以构成多数或最少提供数据副本的可能性。
注意
在两个数据中心之间分布副本集成员可提供优于单个数据中心的好处。在两个数据中心分布中，
如果可能，请在至少三个数据中心中分配成员。对于配置服务器副本集（CSRS），最佳实践是分布在三个（或更多，取决于成员的数量）中心中。如果第三个数据中心的成本过高，则一种分配可能性是，在公司政策允许的情况下，在两个数据中心之间平均分配数据承载成员，并将剩余成员存储在云中。
为确保将主数据中心中的成员选为替代数据中心中的成员之前的主要成员，请将替代数据中心members[n].priority中的成员的数量设置
为低于主数据中心中的成员的数量。
有关详细信息，请参阅 跨两个或多个数据中心分布的副本集。
小费
如果可能，请使用逻辑DNS主机名而不是IP地址，尤其是在配置副本集成员或分片群集成员时。逻辑DNS主机名的使用避免了由于IP地址更改而导致的配置更改。
如果您的应用程序连接到多个副本集，则每个副本集应具有不同的名称。某些驱动程序通过副本集名称对副本集连接进行分组。
以下文档描述了常见的副本集部署模式。根据应用程序的要求，其他模式也是可能且有效的。如果需要，请在您自己的部署中结合每种体系结构的功能：