副本集部署架构
一个副本集的架构会影响该集合的容量和能力。本文档提供了副本集部署的策略，并描述了常见的架构。
对于生产系统，标准的副本集部署是三个成员的副本集。这些集合提供了冗余和容错能力。尽可能避免复杂性，但让您的应用程序需求决定架构。
注意
在滚动升级之外，一个副本集中的所有 mongod 成员应使用相同的主版本 MongoDB。
策略
确定成员数量
根据这些策略在副本集中添加成员。
最大投票成员数
部署奇数个成员
确保副本集有奇数个投票成员。副本集最多可以有7个投票成员。如果您有 偶数 个投票成员，则可以部署另一个数据承载的投票成员，或者如果限制不允许部署另一个数据承载的投票成员，则可以部署一个 仲裁者。
仲裁者不存储数据的副本，并且需要较少的资源。因此，您可以在应用程序服务器或其他共享资源上运行仲裁者。由于没有数据的副本，您可能可以将仲裁者放置在您不会放置副本集其他成员的环境中。请咨询您的安全策略。
警告
避免在 副本集 中部署多个 仲裁者。请参阅 多个仲裁者的注意事项。
要将仲裁者添加到现有的副本集中
在启动具有仲裁者的新副本集之前，您不需要更改集群范围写关注。
考虑容错性
副本集的容错性是指可以变得不可用的成员数量，同时仍然留下足够的成员来选举一个主节点。换句话说，它是集合中成员数量与选举主节点所需投票成员的多数（majority）之间的差值。没有主节点，副本集无法接受写操作。容错性是副本集大小的结果，但这种关系不是直接的。请参阅以下表格
成员数量 | 选举新主节点所需的多数 | 容错性 |
|---|---|---|
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
向副本集添加成员并不总是会提高容错性。然而，在这些情况下，额外的成员可以提供对专用功能的支持，例如备份或报告。
rs.status() 返回副本集的 majorityVoteCount。
使用隐藏和延迟成员用于专用功能
读取密集型应用
副本集旨在实现高可用性和冗余。在大多数情况下，次要成员的负载与主要成员相似。您不应将读取操作直接指向次要副本。
如果您有一个读取密集型应用程序，请考虑使用集群间同步将数据复制到另一个集群以进行读取。
有关次要读取模式的更多信息，请参阅：secondary和secondaryPreferred。
在需求之前增加容量
副本集的现有成员必须具有额外的容量以支持添加新成员。始终在当前需求饱和集合容量之前添加新成员。
地理位置分布成员
为了防止数据中心故障导致数据丢失，至少将一个成员保留在备用数据中心。如果可能，使用奇数个数据中心，并选择成员分布以最大限度地提高即使数据中心丢失，剩余的副本集成员也能形成多数或至少提供数据副本的可能性。
注意
将副本集成员分布在两个数据中心比单个数据中心分布具有优势。在两个数据中心的分布中，
如果其中一个数据中心发生故障，数据仍然可用于读取，这与单个数据中心分布不同。
如果拥有少数成员的数据中心发生故障，副本集仍可提供读写操作。
但是，如果拥有多数成员的数据中心发生故障，副本集变为只读。
如果可能，至少将成员分布到三个数据中心。对于配置服务器副本集（CSRS），最佳实践是跨三个（或更多，取决于成员数量）数据中心进行分布。如果第三个数据中心的成本过高，一种可能的分布方式是将数据承载成员均匀分布在两个数据中心，并在公司政策允许的情况下，将剩余成员存储在云中。
为确保在备用数据中心的主成员在主数据中心的主成员之前被选举，请将备用数据中心成员的 members[n].priority 设置为低于主数据中心的成员。
更多信息，请参阅跨越两个或更多数据中心的副本集
使用标签集指定操作目标
使用副本集标签集可以将读取操作定向到特定的成员，或自定义写入关注点以从特定成员请求确认。
使用日志记录来防止断电
MongoDB默认启用日志记录。日志记录可以在服务中断，如断电和意外重启的情况下防止数据丢失。
主机名
重要
为了避免因IP地址变更而导致的配置更新，请使用DNS主机名而不是IP地址。当配置副本集成员或分片集群成员时，使用DNS主机名而不是IP地址尤为重要。
使用主机名而不是IP地址来配置跨越分割网络边界的集群。从MongoDB 5.0开始，仅配置了IP地址的节点将失败启动验证并且不会启动。
副本集命名
如果您的应用程序连接到多个副本集，则每个集必须具有不同的名称。一些驱动程序根据副本集名称对副本集连接进行分组。
部署模式
以下文档描述了常见的副本集部署模式。根据应用程序的要求，可能还有其他模式和效果。如果需要，可以在自己的部署中结合每种架构的功能。
- 三成员副本集
- 三成员副本集提供了副本集的最小推荐架构。
- 跨两个或更多数据中心分布的副本集
- 地理分布集包括多个位置上的成员，以保护免受特定设施故障的影响，如停电。