副本集部署体系结构

在本页面

• Strategies

• 副本集命名

• Deployment Patterns

replica set的体系结构会影响集合的容量和功能。本文档提供了副本集部署的策略，并介绍了常见的体系结构。

生产系统的标准副本集部署是一个三成员副本集。这些集提供冗余和容错能力。尽可能避免复杂性，但应由您的应用程序要求决定体系结构。

Strategies

确定成员数

根据这些策略在副本集中添加成员。

投票人数上限

副本集最多可包含50 members，但最多只能7 个投票成员。 [1]如果副本集已具有 7 个投票成员，则其他成员必须为non-voting members。

部署奇数会员

确保副本集的投票成员数为奇数。一个副本集最多可以有 7 个投票成员。如果您有个投票成员，则部署另一个具有数据投票成员，或者，如果约束禁止另一个具有数据投票成员，则部署arbiter。

arbiter不存储数据的副本，并且需要较少的资源。结果，您可能在应用程序服务器或其他共享进程上运行仲裁程序。如果没有数据副本，则有可能将仲裁器放置在您不会放置副本集其他成员的环境中。请查阅您的安全策略。

对于以下 MongoDB 版本，具有仲裁器的副本集与pv0相比，pv1增加了w:1回滚的可能性：

• MongoDB 3.4.1

• MongoDB 3.4.0

• MongoDB 3.2.11 或更早版本

See 副本集协议版本.

考虑容错

副本集的“容错”是指可能变得不可用并仍在集合中保留足够数量的成员以选择主要成员的成员数。换句话说，这是集合中成员人数与选举主要成员所需的多数投票成员之间的差。没有主数据库，副本集不能接受写操作。容错是副本集大小的影响，但关系不是直接的。请参见下表：

会员人数	选出新小学的多数	Fault Tolerance
3	2	1
4	3	1
5	3	2
6	4	2

将成员添加到副本集并不会总是提高容错能力。但是，在这些情况下，其他成员可以为专用功能(如备份或报告)提供支持。

将隐藏成员和延迟成员用于专用功能

添加hidden或delayed成员以支持专用功能，例如备份或报告。

重载部署中的负载平衡

在具有非常高的读取流量的部署中，您可以通过将读取分发给辅助成员来提高读取吞吐量。随着部署的增长，将成员添加或移动到备用数据中心以提高冗余性和可用性。

始终确保主要设施能够选出主要设施。

提前增加容量

副本集的现有成员必须具有备用容量以支持添加新成员。始终在当前需求饱和集合容量之前添加新成员。

按地理区域分配成员

为了在数据中心发生故障时保护您的数据，请在备用数据中心中至少保留一个成员。如果可能，请使用奇数个数据中心，并选择成员分布，以最大程度地保证即使丢失数据中心，其余副本集成员也可以构成多数或最少提供数据副本的可能性。

为确保将主数据中心中的成员选为替代数据中心中的成员之前的主要成员，请将替代数据中心中的成员的members[n].priority设置为低于主要数据中心中的成员的members[n].priority。

有关更多信息，请参见跨两个或多个数据中心分布的副本集

使用标签集进行目标操作

使用副本集标签集可以将读取操作定向到特定成员，或者自定义写关注内容以请求特定成员的确认。

使用日记功能防止电源故障

MongoDB 默认情况下启用journaling。日志记录可防止服务中断(例如电源故障和意外重启)导致数据丢失。

副本集命名

如果您的应用程序连接到多个副本集，则每个副本集应具有不同的名称。某些驱动程序通过副本集名称对副本集连接进行分组。

Deployment Patterns

以下文档描述了常见的副本集部署模式。根据应用程序的要求，其他模式也是可能且有效的。如果需要，请在您自己的部署中结合每种体系结构的功能：

• 三个成员副本集

  • 三成员副本集为副本集提供了建议的最低体系结构。

• 跨两个或多个数据中心分布的副本集

  • 地理位置分散的集合包括位于多个位置的成员，以防止发生特定于设施的故障，例如断电。

[1]	虽然建议将副本集用于生产，但副本集最多可支持50 members。如果您的部署需要 50 个以上的成员，则需要使用master-slave复制。但是，主从复制缺少自动故障转移功能。