关于MongoDB复制，你了解多少（附副本集常见任务教程）

MongoDB中的副本集是一组维护相同数据集合的  mongod进程。副本集提供了冗余和高可用性，并且这是所有生产部署的基础。本节介绍MongoDB中的复制以及副本集的组件和体系结构，并提供副本集常见任务的教程。

复制提供了冗余并增加了数据可用性。对于不同数据库服务器上的多个数据副本，复制为防止单台数据库服务器故障提供了一定程度的容错能力。

在某些情况下，复制可以提高读取性能，因为客户端可以将读操作发送到不同的服务器上。在不同的数据中心维护数据副本可以提高分布式应用程序的数据本地化和可用性。您还可以维护额外的副本以实现特殊用途，比如灾难恢复、报告或备份。

主节点 接收所有的写操作。一个副本集仅有一个主节点能够用 { w: "majority" } 写关注点级别来确认写操作；虽然在某些情况下，另一个mongod的实例也可以暂时认为自己是主节点。[1] 主节点会将其数据集合所有的变化记录到操作日志中，即oplog。有关主节点操作的更多信息，请参见 副本集主节点。

副本节点复制主节点的oplog，并将这些操作应用于它们的数据集，这样以便副本节点的数据集能反映出主节点的数据集。如果主节点不可用，一个候选的副本节点将会发起选举并使之成为新的主节点。有关副本成员的更多信息，请参见副本集副本成员。

在某些情况下(比如您有一个主节点和一个副本节点，但由于成本约束无法添加另一个副本节点)，您可以选择将一个  mongod 实例作为仲裁节点添加到一个副本集中。仲裁节点参与选举但不持有数据(即不提供数据冗余)。有关仲裁节点的更多信息，请参见副本集仲裁节点。

仲裁节点永远只能是仲裁节点，但在选举过程中主节点也许会降级成为副本节点， 副本节点也可能会升级成为主节点。

有关复制机制的更多信息，请参见副本集Oplog和副本集数据同步。

从4.2版本开始（从4.0.6开始也是可行的），副本集的副本成员会记录oplog中应用时间超过慢操作阈值的慢操作条目。这些慢oplog信息被记录在副本节点的诊断日志中，其路径位于 REPL 组件的文本 applied op: took ms中。这些慢日志条目仅仅依赖于慢操作阈值。它们不依赖于日志级别（无论是系统还是组件级别）、过滤级别，或者慢操作采样比例。过滤器不会捕获慢日志条目。

复制延迟 指的是将主节点的写操作拷贝(即复制)到副本节点所花费的时间。一些小的延迟期可能是可以接受的，但是随着复制延迟的增长，会出现严重的问题，包括引起主节点的缓存压力。

从MongoDB 4.2开始，管理员可以限制主节点应用写操作的速度，目的是将 majority committed 延迟保持在可配置参数 flowControlTargetLagSeconds的最大值之下。

默认情况下，流控制是启用的。

注意：

为了进行流控制，复制集/分片集群必须满足：参数featureCompatibilityVersion (FCV) 设置为 4.2并启用majority读关注点。也就是说，如果FCV不是  4.2 ，或者读关注点majority被禁用，那么启用流控制将不起作用。

启用流控制后，当延迟快接近 flowControlTargetLagSeconds参数指定的秒数时，主节点上的写操作必须首先获得许可单（tickets)才可以获取写锁。通过限制每秒发出的许可单的数量，流控制机制可以将延迟保持在目标数值之下。

为获取更多信息，请参见检查复制延迟和流控制。

副本集在选举成功前是无法处理写操作的。如果读请求被配置运行在副本节点上，则当主节点下线时，副本集可以继续处理这些请求。

假设采用默认的副本配置选项，集群选择新主节点的中间过渡时间通常不应超过12秒。这包括了将主节点标记为unavailable、发起以及完成一次选举的时间。您可以通过修改 settings.electionTimeoutMillis 复制配置选项来调整这个时间期限。网络延迟等因素可能会延长完成副本集选举所需的时间，从而影响您的集群在没有主节点的情况下运行的时间。这些因素取决于您实际的集群架构情况。

将 electionTimeoutMillis复制配置选项从默认的 10000(10秒)降低可以更快地检测主节点故障。然而，由于诸如临时性的网络延迟等因素，集群可能会更频繁地发起选举，即使主节点在其他方面是健康的。这也许会增加w : 1 级别写操作发生回滚的可能性。

您的应用程序连接逻辑应该包括对自动故障转移和后续选举的容错处理能力。从MongoDB 3.6开始，MongoDB驱动程序可以探测到主节点的丢失，并自动重试某些写操作 一次，提供额外的自动故障转移和选举的内置处理:

• MongoDB 4.2兼容的驱动程序默认启用可重试写
• MongoDB 4.0和3.6兼容的驱动程序必须通过在 连接字符串中包含 retryWrites=true来显式地启用可重试写。

请参见 副本集选举来获取副本集选举的完整信息。

为了解更多关于MongoDB失败处理的信息，请参见：

• 副本集选举
• 可重试写
• 副本集故障期间的回滚

No 5 读操作

默认情况下，客户端从主节点读取[1]；然而，客户端可以定义一个读偏好 将读操作发送给副本节点。

异步复制至副本节点，意味着从副本节点读取返回的数据不能反映主节点上数据的状态。

包含读操作的多文档事务必须使用读偏好 primary。在给定的事务中所有操作都必须路由至相同的成员节点。

为了解更多关于副本集读的信息，请参见读偏好。

根据读关注点，客户端可以在写持久化前看到写结果：

• 不管写的write concern级别是什么，其他使用了读关注点级别为  "local" 或  "available" 的客户端，可以在发起写操作的客户端确认其写成功之前查看该客户端写的结果。
• 使用了读关注点级别为  "local" 或  "available" 的客户端，能读取在副本集故障转移期间可能随后被回滚掉的数据。

对于多文档事务中的操作，当事务提交时，在事务中所做的所有数据更改都会被保存并在事务外部可见。也就是说，事务在回滚其他更改时不会提交某些更改。

在事务提交之前，事务中所做的数据更改在事务外部是不可见的。

然而，当一个事务写入多个分片时，并不是所有外部的读操作都需要等待提交的事务的结果在分片中可见。例如，如果提交了一个事务，并且在分片a上可以看到写1，但是在分片B上还不能看到写2，那么外部读关注点为  "local" 的读可以在不看到写2的情况下读取写1的结果。

更多请参见Read Isolation, Consistency, and Recency。

从MongoDB 4.0开始，副本集支持多文档事务。

包含读操作的多文档事务必须使用读偏好  primary。给定事务中所有的操作都必须路由至相同的成员节点。

在事务提交之前，事务中所做的数据更改在事务外部是不可见的。

然而，当一个事务写入多个分片时，并不是所有外部的读操作都需要等待提交的事务的结果在分片中可见。例如，如果提交了一个事务，并且在分片a上可以看到写1，但是在分片B上还不能看到写2，那么外部读关注点为  "local" 的读可以在不看到写2的情况下读取写1的结果。

从MongoDB 3.6开始，副本集和分片集群支持变更流。变更流允许应用程序访问实时数据更改，而不需要跟踪oplog的复杂性和风险。应用程序可以使用变更流来订阅一个或多个集合上的所有数据更改。

副本集提供了许多选项来支持应用程序的需求。例如，你可以使用多数据中心中的成员来部署一个副本集，或者通过调整一些成员的 members[n].priority 来控制选举结果。副本集还支持用于报告、灾难恢复或备份功能的专用成员。

更多有关信息请参见优先级0的副本集成员，隐藏副本集成员和延迟副本集成员 。

注意：

(1, 2) 在 某些场景下, 一个复制集中的两个节点可能会认为它们是主节点，但最多，他们中的一个将能够完成写关注点为{ w: “majority” }写操作。可以完成 { w: “majority” } 写的节点是当前主节点，而另一个节点是原先的主节点，通常是由于网络分区导致它还没有意识到自己的降级。当这种情况发生时，连接到原先主节点的客户端尽管已经请求了读偏好primary，但可能还会观察到过时的数据，并且对原先主节点新写的操作最终将回滚掉。

译者：李正洋

MongoDB中文社区翻译小组成员

目前在传统金融行业从事DBA职务，5年+工作经验，主要负责公司oracle/mongodb/es/redis各类数据库及数据中心监控平台运维工作，oracle ocp，MongoDB认证专家，RHCE，现阶段对开源分布式数据库、云计算等领域有很大兴趣；平时喜欢打羽毛球、看电影等。

原文链接：

https://docs.mongodb.com/manual/replication/