mongoDB-副本

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

冗余和数据可用性

复制提供了冗余并增加了数据可用性。对于不同数据库服务器上的多个数据副本，复制提供了一定程度的容错性，防止丢失单个数据库服务器。
在某些情况下，复制可以提供增加的读容量，因为客户机可以将读操作发送到不同的服务器。在不同的数据中心维护数据副本可以提高分布式应用程序的数据局部性和可用性。您还可以为专用目的维护额外的副本，例如灾难恢复、报告或备份。

MongoDB复制

副本集是一组维护相同数据集的mongod实例。副本集包含多个数据承载节点和一个可选的仲裁节点。在数据承载节点中，一个且仅有一个成员为主节点，其他节点为次节点。

主节点接收所有写操作。一个复制集只能有一个主节点，这个主节点可以用{w: “majority”}写关心来确认写;虽然在某些情况下，另一个mongod的实例也可以暂时认为自己是主要的。原始记录的所有变化，其数据集在其操作日志，即oplog。有关主节点操作的更多信息，请参见复制集主节点。

辅助服务器复制主服务器的oplog，并将操作应用到它们的数据集，以便二级服务器的数据集反映主服务器的数据集。有关辅助成员的更多信息，请参见复制集辅助成员。

在某些情况下(比如您有一个主服务器和一个辅助服务器，但是成本限制禁止添加另一个辅助服务器)，您可以选择将一个mongod实例作为仲裁程序添加到一个副本集中。仲裁者参与选举但不持有数据(即不提供数据冗余)。有关仲裁程序的更多信息，请参见复制集仲裁程序。

公断人永远是公断人，而预选人可以退位成为第二候选人，而第二候选人可以在选举中成为预选人。

异步复制

二级服务器复制主服务器的oplog并异步地将操作应用到它们的数据集。通过让次服务器的数据集反映主服务器的数据集，副本集可以在一个或多个成员失败的情况下继续运行。

缓慢操作

从第4.2版开始(也可以从4.0.6开始使用),一个副本集的次要成员现在打印日志条目比缓慢操作阈值更长。这些慢的oplog消息在应用op的REPL组件下的诊断日志中登录到的第二部分,< oplog条目>以< num > ms为例。这些慢的oplog条目只依赖于缓慢的操作阈值。它们不依赖于日志级别(无论是在系统或组件级别),还是分析级别,或者是缓慢的操作样本率。profiler没有捕获慢的oplog条目。

复制滞后和流量控制

复制延迟指的是将主写操作复制(即复制)到次写操作所花费的时间。一些小的延迟期可能是可以接受的，但是随着复制延迟的增长，会出现严重的问题，包括在主服务器上构建缓存压力。

从MongoDB 4.2开始，管理员可以限制主应用写操作的速度，目的是在可配置的最大值flowControlTargetLagSeconds下保持大多数提交延迟。

默认情况下,启用流量控制。

为了进行流量控制,复制集/sharded集群必须有:4.2和read关心多数启用的特性。也就是说,如果FCV不是4.2,如果读取关注点多数都是禁用的,那么启用流控制就没有影响。

启用了流控制后，随着延迟越来越接近flowControlTargetLagSeconds，主节点上的写操作必须在获取锁以应用写操作之前获得票据。通过限制每秒发出的票据数，流控制机制试图将延迟保持在目标之下。

有关更多信息，请参见检查复制延迟和流控制。

自动故障转移

当一个主与指定的选区的其他成员没有与配置的electionTimeoutMillis周期(默认情况下10秒)进行通信时,一个合格的二次调用来提名自己作为新主。集群试图完成新的初选和恢复正常操作的选举。

在选举成功完成之前,复制集不能处理操作。如果这些查询被配置为在二级上运行,那么复制集可以继续服务阅读查询。

在集群选择新主的过程中,中值时间不应该通常超过12秒,假设默认的复制配置设置。这包括将主标记为不可用的时间和完成选举所需的时间。你可以通过修改设置来调整这个时间段。electionTimeoutMillis复制配置选项。诸如网络延迟等因素可能会延长复制集选举所需的时间,从而影响集群可能在没有主的情况下运行的时间。这些因素依赖于特定的集群架构。

从默认的10000(10秒)中降低electionTimeoutMillis复制配置选项,可以更快地检测主故障。然而,集群可能会更频繁地调用选举,因为即使主要的是健康的,也会出现临时网络延迟。这可以导致w:1写操作增加回滚。

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

• 默认情况下，MongoDB 4.2兼容的驱动程序支持可重试写。
• MongoDB 4.0和3.6兼容的驱动程序必须明确地允许retryable写入,包括retrywrite = true在连接字符串中。

有关副本集选举的完整文档，请参阅副本集选举。

要了解更多关于MongoDB的故障转移过程，请参阅:

• 副本集选举
• 可重试写入
• 复制集故障转移期间的回滚

读操作

复制集读选项

默认情况下,客户端从主[1]中读取;然而,客户端可以指定读取倾向将读取操作发送到二级。

对二级服务器的异步复制意味着从二级服务器读取的数据可能不会反映主服务器上数据的状态。

包含读操作的多文档事务必须使用读首选项主。给定事务中的所有操作都必须路由到相同的成员。

有关从复制集读取的信息,请参见阅读偏好。

数据可见性

根据读取关心，客户端可以看到写入结果，在写入序列化之前：

• 无论一个写入的写入关心，其他客户端使用“local”或“available”读取关系可以看到写入操作的结果，在写入操作通知到客户端之前。
• 客户端使用“local”或“available”读取关心可以读取数据，这些数据可能之后因为复制集故障转移而回滚。

对于在多文档事务的操作，当一个事务提交时，所有在事务中的数据改变会保存并且对外部事务可见。也就是，当回滚其他事务时，一个事务不会提交它的一些修改。

直到一个事务提交，事务中的数据修改不会对外部事务可见。

然而， 当一个事务写入到多个碎片时，不是所有的外部读取操作需要等待事务提交的结果对所有碎片可见。比如，如果一个事务提交了并且写入1在碎片A可见但是写入2对碎片B还不可见，一个读取关心为“local”的读取可以读写入1的结果而看不到写入2。

需要更多关于MongoDB的读取隔离，一致性和最新的信息，参见读取隔离，一致性和最新。

事务

从MongoDB 4.0开始，支持复制集的多文档事务。

包含读操作的多文档事务必须使用读取偏好primary。在一个给定事务的所有操作必须路由到同一成员。

直到一个事务提交，事务中的数据改变才能被外部事务可见。

然而，当一个事务写入到多个碎片时，不是所有的外部读取操作需要等待提交事务的结果对所有的碎片可见。比如，如果一个事务提交了并且在碎片A写入1可见但碎片B写入2还不可见，外部读取关心为“local”的读取可以读到写入1的结果而看不到写入2。

修改流

从MongoDB 3.6开始，支持复制集和碎片集群的修改流。修改流允许程序访问实时数据改变而没有尾随oplong的复杂性和风险。程序可以使用修改流来订阅一个集合或多个集合的数据改变。

额外功能

副本集提供一系列选项来支持程序需要。比如，可能使用在多个数据中心的成员来部署一个复制集，或者通过调整一些成员的members[n].priority来控制选举的结果。复制集也支持专用成员的报告，灾难恢复，或备份功能。

参见优先级0副本集成员，隐藏复制集成员和延迟复制集成员获取更多信息。