mongoDB复制（译 v4.0）
- 冗余和数据可用性
- MongoDB中的复制
- 异步复制
- 自动故障转移
- 读操作
- 事务
- 变更流
- 其它功能
注： MongoDB Atlas上托管的所有数据库都配置为副本集。 Atlas可以轻松添加和删除首选云提供商的任何区域中的副本集成员。注册MongoDB Atlas。
MongoDB中的副本集是一组维护相同数据集的mongod进程。副本集提供冗余和高可用性，是所有生产部署的基础。本节介绍MongoDB中的复制以及副本集的组件和体系结构。该部分还提供了与副本集相关的常见任务的教程。
冗余和数据可用性
复制提供冗余并提高数据可用性。通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。
在某些情况下，复制可以提供更强的读取能力，因为客户端可以将读取操作发送到不同的服务器。在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。您还可以为专用目的维护其他副本，例如灾难恢复，报告或备份。
MongoDB中的复制
副本集是一组维护相同数据集的mongod实例。副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，有且仅有一个成员被视为主节点，而其他节点被视为从节点。
主节点接收所有写操作。副本集只能有一个能够确认具有写入关注的写入的主节点;虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主节点。[1]主节点将所有的变更记录到它的操作日志的数据集中，即oplog。有关主节点操作的详细信息，请参阅副本集主节点。
从节点复制主节点的oplog并将操作应用于其数据集，以使从节点的数据集反映主节点的数据集。 如果主节点不可用，则符合条件的从节点将有机会选择它自己成为主节点。 有从节点成员的详细信息，请参阅副本集从节点成员。
您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁者是一个提供副本集仲裁功能的好方法，其资源消耗成本比具有数据集的全功能副本集成员更低。 如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的大多数投票。 仲裁者不需要专用硬件。 有关仲裁器的更多信息，请参阅副本集仲裁者。
仲裁者将永远是仲裁者，而主节点有可能降级成为从节点，而从节点可能在一次选举期间成为主节点。
异步复制
从节点异步应用主节点的操作。 通过在主节点之后应用操作，尽管一个或多个成员失败，但集合仍可继续运行。 有关复制机制的详细信息，请参阅副本集Oplog和副本集数据同步。
副本集的从节点现在记录oplog项的时间要比应用的慢操作阈值长。在REPL组件下的诊断日志中为从节点记录这些慢速oplog消息，其应用的文本 op 是：<oplog entry> took <num>ms。 这些慢oplog条目仅取决于慢速操作阈值。 它们不依赖于日志级别（系统级别或组件级别），性能分析级别或慢操作采样率。 分析器不捕获慢速oplog条目。 有关更多信息，请参阅慢Oplog应用程序。
自动故障转移
当主节点超过配置的electionTimeoutMillis（默认为10秒）不能与集合的其它成员通信时，符合条件的从节点要求选举将自己指定为新主节点。 群集尝试完成新主节点的选举并恢复正常操作。
在选举成功完成之前，副本集无法处理写入操作。 如果查询被配置为主节点脱机时在从节点上运行，则副本集可以继续提供读取查询。
假设是默认的副本配置设置，群集选择新主节点之前的中位时间通常不应超过12秒。 这包括将主节点标记为不可用并调用和完成一次选举所需的时间。 您可以通过修改复制配置选项settings.electionTimeoutMillis来调整此时间段。 网络延迟等因素可能会延长副本集选举完成所需的时间，从而影响群集在没有主节点的情况下运行的时间。 这些因素取决于您的特定群集体系结构。
将复制配置选项electionTimeoutMillis从默认的10000（10秒）降低可以更快地检测到主节点故障。 但是，由于诸如临时网络延迟等因素，群集可能会更频繁地调用选举，即使主节点是正常的。 这可能导致w：1写入操作的回滚增加。
您的应用程序连接逻辑应包括自动故障转移和后续选举的容差。
版本3.6中的新功能：MongoDB 3.6+驱动程序可以检测主数据库的丢失并自动重试某些写操作一次，从而提供额外的内置自动故障转移和选举处理。
有关副本集选举的完整文档，请参阅副本集选举。
要了解有关MongoDB故障转移过程的更多信息，请参阅：
读操作
默认情况下，客户端从主[1]读取; 但是，客户端可以指定读取首选项以将读取操作发送到从节点。 对从节点的异步复制意味着从从节点读取的数据不能反映主节点上数据的状态。 有关从副本集读取的信息，请参阅读取首选项。
包含读取操作的多文档事务必须将读取首选项设置为主节点（use read preference primary）。
给定事务中的所有操作都必须路由到同一成员。
根据write concern，客户端可以在写入持久之前查看写入结果：
- 无论是否write concern，使用“本地”或“可用”readConcern的其他客户端都可以在向发布客户端确认写入操作之前查看写入操作的结果。
对于多文档事务中的操作，在事务提交之前，事务的数据更改在事务外部不可见。 但是，其他客户端可以在向发布客户端确认提交操作之前查看事务提交时的结果。
- 使用“本地”或“可用”readConcern的客户端可以读取在副本集故障转移期间可能随后回滚的数据。
有关MongoDB的读取隔离、一致性和recency的更多信息，请参阅Read Isolation, Consistency, and Recency。
事务
从MongoDB 4.0开始，多文档事务可用于副本集。
包含读取操作的多文档事务必须使用read preference primary。
给定事务中的所有操作都必须路由到同一成员。
变更流
从MongoDB 3.6开始，变更流可用于副本集和分片集群。 变更流允许应用程序访问实时数据变更，而不会产生拖尾oplog的复杂性和风险。 应用程序可以使用变更流来订阅一个或多个集合上的所有数据更改。
其它功能
副本集提供了许多选项来支持应用程序需求。 例如，您可以部署包含在多个数据中心的成员的副本集，或通过调整一些成员的members[n].priority来控制选举结果。 副本集还支持报告、灾难恢复或备份功能的专用成员。
有关详细信息，请参阅优先级0副本集成员，隐藏副本集成员和延迟副本集成员。
1（1,2）在某些情况下，副本集中的两个节点可能会暂时认为它们是主要节点，但最多其中一个节点将能够使用 { w: "majority" }write concern完成写入。 可以完成{ w: "majority" } 写入的节点是当前主节点，而另一个节点是以前的主节点，通常由于网络分区尚未意识到其已降级。 发生这种情况时，尽管已经被要求设置读首选项为主节点，连接到前一个主节点的客户端仍可能会观察到过时数据，对前一个主节点的新写入最终将回滚。
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。