MongoDB复制
最后更新于
在本页
MongoDB中的副本集是一组维护相同数据集合的 进程。副本集提供了冗余和，并且这是所有生产部署的基础。本节介绍MongoDB中的复制以及副本集的组件和体系结构。本节还提供了副本集常见任务的教程。
复制提供了冗余并增加了 。对于不同数据库服务器上的多个数据副本，复制为防止单台数据库服务器故障提供了一定程度的容错能力。
在某些情况下，复制可以提高读取性能，因为客户端可以将读操作发送到不同的服务器上。在不同的数据中心维护数据副本可以提高分布式应用程序的数据本地化和可用性。您还可以维护额外的副本以实现特殊用途，比如灾难恢复、报告或备份。
副本集是一组维护相同数据集合的 实例。副本集包含多个数据承载节点和一个可选的仲裁节点。在数据承载节点中，有且仅有一个成员为主节点，其他节点为从节点。
从节点复制主节点的oplog并异步地应用操作到它们的数据集。通过让从节点的数据集反映主服务器的数据集，副本集可以在一个或多个成员失败的情况下继续运行。
注意
当主节点无法和集群中其他节点通信的时间超过参数electionTimeoutMillis配置的期限时（默认10s），一个候选的从节点会发起选举来推荐自己成为新主节点。集群会尝试完成一次新主节点的选举并恢复正常的操作。
MongoDB 4.2兼容的驱动程序默认启用可重试写
为了解更多关于MongoDB失败处理的信息，请参见：
在事务提交之前，事务中所做的数据更改在事务外部是不可见的。
然而，当一个事务写入多个分片时，并不是所有外部的读操作都需要等待提交的事务的结果在分片中可见。例如，如果提交了一个事务，并且在分片a上可以看到写1，但是在分片B上还不能看到写2，那么外部读关注为 ["local"]([[https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local)"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local]%28https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local%29")) 的读可以在不看到写2的情况下读取写1的结果。
在事务提交之前，事务中所做的数据更改在事务外部是不可见的。
然而，当一个事务写入多个分片时，并不是所有外部的读操作都需要等待提交的事务的结果在分片中可见。例如，如果提交了一个事务，并且在分片a上可以看到写1，但是在分片B上还不能看到写2，那么外部读关注点为 ["local"]([[https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local)"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local]%28https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local%29")) 的读可以在不看到写2的情况下读取写1的结果。
[1]
译者：李正洋
MongoDB中文社区官网
微信服务号 ——最新资讯和优质文章
Mongoing中文社区（mongoing-mongoing）
微信订阅号 ——发布文档翻译内容
MongoDB中文用户组（mongoing123）
官方微信号 —— 官方最新资讯
MongoDB数据库（MongoDB-China）
MongoDB中文社区组委会成员介绍
MongoDB中文社区翻译小组介绍
MongoDB中文社区微信技术交流群
添加社区助理小芒果微信（ID:mongoingcom），并备注 mongo
MongoDB中文社区会议及文档资源
MongoDB中文社区大咖博客
MongoDB白皮书
MongoDB初学者教程-7天入门
社区活动邮件订阅
接收所有的写操作。一个副本集仅有一个主节点能够用[{ w: "majority" }]([[https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority)"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority]%28https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority%29")) 写关注点级别来确认写操作；虽然在某些情况下，另一个mongod的实例也可以暂时认为自己是主节点。 主节点会将其数据集合所有的变化记录到操作日志中，即.。有关主节点操作的更多信息，请参见 。
从节点复制主节点的oplog，并将这些操作应用于它们的数据集，这样以便从节点的数据集能反映出主节点的数据集。如果主节点不可用，一个候选的从节点将会发起选举并使之成为新的主节点。有关副本成员的更多信息，请参见。
在某些情况下(比如您有一个主节点和一个从节点，但由于成本约束无法添加另一个从节点)，您可以选择将一个 实例作为 添加到一个副本集中。仲裁节点参与但不持有数据(即不提供数据冗余)。有关仲裁节点的更多信息，请参见。
永远只能是仲裁节点，但在选举过程中也许会降级成为 ， 也可能会升级成为主节点。
有关复制机制的更多信息，请参见 和 。
从4.2版本开始（从4.0.6开始也是可行的），副本集的副本成员会记录oplog中应用时间超过慢操作阈值的慢操作条目。这些慢oplog信息被记录在从节点的 中，其路径位于 组件的文本applied op: took ms中。这些慢日志条目仅仅依赖于慢操作阈值。它们不依赖于日志级别（无论是系统还是组件级别）、过滤级别，或者慢操作采样比例。过滤器不会捕获慢日志条目。
指的是将的写操作拷贝(即复制)到 所花费的时间。一些小的延迟期可能是可以接受的，但是随着复制延迟的增长，会出现严重的问题，包括引起主节点的缓存压力。
从MongoDB 4.2开始，管理员可以限制主节点应用写操作的速度，目的是将 延迟保持在可配置参数的最大值之下。
默认情况下，流控制是。
为了进行流控制，复制集/分片集群必须满足：参数 设置为4.2并启用读关注点。也就是说，如果FCV不是 4.2 ，或者读关注点majority被禁用，那么启用流控制将不起作用。
启用流控制后，当延迟快接近 参数指定的秒数时，主节点上的写操作必须首先获得许可单才可以获取写锁。通过限制每秒发出的许可单的数量，流控制机制可以将延迟保持在目标数值之下。
为获取更多信息，请参见检查和。
副本集在选举成功前是无法处理写操作的。如果读请求被配置运行在 上，则当主节点下线时，副本集可以继续处理这些请求。
假设采用默认的，集群选择新主节点的中间过渡时间通常不应超过12秒。这包括了将主节点标记为、发起以及完成一次 的时间。您可以通过修改 复制配置选项来调整这个时间期限。网络延迟等因素可能会延长完成副本集选举所需的时间，从而影响您的集群在没有主节点的情况下运行的时间。这些因素取决于您实际的集群架构情况。
将复制配置选项从默认的10000(10秒)降低可以更快地检测主节点故障。然而，由于诸如临时性的网络延迟等因素，集群可能会更频繁地发起选举，即使主节点在其他方面是健康的。这也许会增加 级别写操作发生的可能性。
您的应用程序连接逻辑应该包括对自动故障转移和后续选举的容错处理能力。从MongoDB 3.6开始，MongoDB驱动程序可以探测到主节点的丢失，并自动 一次，提供额外的自动故障转移和选举的内置处理:
MongoDB 4.0和3.6兼容的驱动程序必须通过在 中包含来显式地启用可重试写。
请参见 来获取副本集选举的完整信息。
默认情况下，客户端从主节点读取；然而，客户端可以定义一个 将读操作发送给从节点。
至从节点，意味着从节点读取返回的数据不能反映主节点上数据的状态。
包含读操作的必须使用读偏好。在给定的事务中所有操作都必须路由至相同的成员节点。
为了解更多关于副本集读的信息，请参见。
根据读关注，客户端可以在写前看到写结果：
不管写的 级别是什么，其他使用了读关注级别为 ["local"]([[https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local)"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local]%28https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local%29")) 或 ["available"]([[https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available](https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available)"](https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available]%28https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available%29")) 的客户端，可以在发起写操作的客户端确认其写成功之前查看该客户端写的结果。
使用了读关注级别为 ["local"]([[https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local)"](https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local]%28https://docs.mongodb.com/manual/reference/read-concern-local/#readconcern."local%29")) 或 ["available"]([[https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available](https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available)"](https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available]%28https://docs.mongodb.com/manual/reference/read-concern-available/#readconcern."available%29")) 的客户端，能读取在副本集故障转移期间可能随后被 掉的数据。
对于中的操作，当事务提交时，在事务中所做的所有数据更改都会被保存并在事务外部可见。也就是说，事务在回滚其他更改时不会提交某些更改。
有关MongoDB读隔离、一致性和近因性的更多信息，请参见。
从MongoDB 4.0开始，副本集支持。
包含读操作的必须使用读偏好 。给定事务中所有的操作都必须路由至相同的成员节点。
从MongoDB 3.6开始，副本集和分片集群支持。变更流允许应用程序访问实时数据更改，而不需要跟踪oplog的复杂性和风险。应用程序可以使用变更流来订阅一个或多个集合上的所有数据更改。
副本集提供了许多选项来支持应用程序的需求。例如，你可以使用来部署一个副本集，或者通过调整一些成员的 来控制选举结果。副本集还支持用于报告、灾难恢复或备份功能的专用成员。
更多有关信息请参见，和 。
(, ) 在 , 一个复制集中的两个节点可能会认为它们是主节点，但最多，他们中的一个将能够完成写关注点为[{ w: "majority" }]([) 可以完成 [{ w: "majority" }]([[https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority)"](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority]%28https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority%29")) 写的节点是当前主节点，而另一个节点是原先的主节点，通常是由于导致它还没有意识到自己的降级。当这种情况发生时，连接到原先主节点的客户端尽管已经请求了读偏好，但可能还 会观察到过时的数据，并且对原先主节点新写的操作最终将回滚掉。
原文链接：
