参考 > 复写
甲副本集 MongoDB中是一组mongod
其保持相同的数据集的过程。副本集提供冗余和
高可用性,并且是所有生产部署的基础。本节介绍MongoDB中的复制以及副本集的组件和体系结构。本节还提供了与副本集相关的常见任务的教程。
复制提供冗余并提高 数据可用性。使用不同数据库服务器上的多个数据副本,复制可提供一定程度的容错能力,以防止丢失单个数据库服务器。
在某些情况下,复制可以提供更大的读取容量,因为客户端可以将读取操作发送到不同的服务器。在不同数据中心中维护数据副本可以提高数据本地性和分布式应用程序的可用性。您还可以维护其他副本以用于专用目的,例如灾难恢复,报告或备份。
副本集是一组mongod
维护相同数据集的实例。一个副本集包含多个数据承载节点和一个仲裁器节点(可选)。在数据承载节点中,只有一个成员被视为主要节点,而其他节点则被视为次要节点。
所述主节点接收所有的写操作。副本集只能有一个能够确认与
写入有关的写入的主数据库。尽管在某些情况下,另一个mongod实例可能会暂时认为自己也是主要实例。
[1]主数据库在其操作日志(即oplog)中记录对其数据集的所有更改。有关主节点操作的更多信息,请参见“ 副本主集”。{ w: "majority" }
该次级复制初级的OPLOG和应用操作的数据集,使得次级数据集反映了主要的数据集。如果主要节点不可用,则符合条件的次要节点将进行选举以自行选举新的主要节点。有关辅助成员的更多信息,请参阅副本集辅助成员。
在某些情况下(例如您有一个主服务器和一个辅助服务器,但由于成本限制,禁止添加另一个辅助服务器),您可以选择将一个mongod
实例作为仲裁器添加到副本集
。仲裁人参加
选举,但不保存数据(即不提供数据冗余)。有关仲裁器的更多信息,请参见副本集仲裁器。
辅助节点复制主节点的操作日志,并将操作异步应用于其数据集。通过使次要节点的数据集反映主要节点的数据集,即使一个或多个成员失败,副本集也可以继续运行。
有关复制机制的更多信息,请参阅 副本集操作日志和副本集数据同步。
从版本4.2(也从版本4.0.6开始可用)开始,副本集的辅助成员现在
记录的oplog条目所花费的时间比慢操作阈值要长。这些缓慢的oplog消息会在组件下的文本中记录为次要日志。这些慢操作日志条目仅取决于慢操作阈值。它们不依赖于日志级别(在系统级别或组件级别),配置级别或运行缓慢的采样率。探查器不会捕获缓慢的操作日志条目。diagnostic log
REPL
applied
op: <oplog entry> took <num>ms
复制滞后是指将主操作上的写操作复制(即复制)到辅助上所花费的时间 。可以接受一些小的延迟时间,但是随着复制滞后的增加会出现严重的问题,包括在主数据库上增加缓存压力。
从MongoDB 4.2开始,管理员可以限制主数据库应用其写入的速率,以将延迟保持在可配置的最大值以下。majority
committed
flowControlTargetLagSeconds
默认情况下,流量控制为enabled
。
注意
为了启用流控制,副本集/分片集群必须具有:featureCompatibilityVersion(FCV) of
4.2
并读取关注。也就是说,如果未启用FCV 或禁用了多数读功能,则启用的流控制无效。majority enabled
4.2
启用流量控制后,随着滞后时间逐渐接近
flowControlTargetLagSeconds
,主锁上的写操作必须先获得票证,然后才能锁定应用写操作。通过限制每秒发出的票证数量,流控制机制尝试将滞后保持在目标以下。
当主节点与集合中的其他成员的通信electionTimeoutMillis
时间超过配置的时间段(默认为10秒)时,合格的辅助节点将要求选举以提名自己为新的主节点。群集尝试完成新主数据库的选择并恢复正常操作。
副本集无法处理写入操作,直到选举成功完成。如果将副本集配置为在主副本处于脱机状态时在次副本上运行,则副本集可以继续提供读取查询 。
假设为default,则集群选择新的主节点之前的中值时间通常不应超过12秒。这包括将主要节点标记为不可用并致电并完成选举所需的时间。您可以通过修改复制配置选项来调整此时间段
。网络延迟之类的因素可能会延长完成副本集选举所需的时间,进而影响您的群集在没有主数据库的情况下可以运行的时间。这些因素取决于您的特定群集体系结构。replica
configuration settings
settings.electionTimeoutMillis
将electionTimeoutMillis
复制配置选项从默认值10000
(10秒)降低可导致更快地检测主要故障。但是,由于临时网络等待时间等因素,群集可能会更频繁地调用选举,即使主节点处于其他状态也是如此。这可能会导致增加回滚为
宽:1次的写操作。
您的应用程序连接逻辑应包括对自动故障转移和后续选举的容忍度。从MongoDB 3.6开始,MongoDB驱动程序可以检测到主数据库的丢失,并可以一次自动 重试某些写入操作,从而提供了自动故障转移和选择的其他内置处理:
retryWrites=true
在连接字符串中包含来显式启用可重试的写入。要了解有关MongoDB的故障转移过程的更多信息,请参阅:
默认情况下,客户端从主服务器[1]读取数据;但是,客户端可以指定读取首选项,以将读取操作发送到辅助对象。
异步复制到辅助数据库意味着从辅助数据库读取数据可能会返回不反映主数据库上数据状态的数据。
包含读取操作的多文档事务必须使用读取首选项primary
。给定事务中的所有操作都必须路由到同一成员。
有关从副本集读取的信息,请参见“ 读取首选项”。
根据读取的关注点,客户端可以在持久写入之前看到写入结果:
"local"
或"available"
读关注的客户端都可以在向发布客户端确认写操作之前看到写操作的结果。"local"
或"available"
读取关注点的客户端可以读取数据,这些数据随后可能会在副本集故障转移期间回滚。对于多文档事务中的操作,在提交事务时,将保存在事务中进行的所有数据更改,并在事务外部可见。也就是说,一个事务在回滚其他事务时将不会提交其某些更改。
在提交事务之前,在事务外部看不到在事务中进行的数据更改。
但是,当一个事务写入多个分片时,并非所有外部读取操作都需要等待已提交事务的结果在所有分片上可见。例如,如果提交了一个事务,并且在分片A上可以看到写1,但是在分片B上仍然看不到写2,则外部读处于读关注状态
"local"
可以读取写1的结果而看不到写2。
有关MongoDB的读取隔离,一致性和新近度的更多信息,请参阅读取隔离,一致性和新近度。
从MongoDB 4.0开始,多文档事务可用于副本集。
包含读取操作的多文档事务必须使用读取首选项primary
。给定事务中的所有操作都必须路由到同一成员。
在提交事务之前,在事务外部看不到在事务中进行的数据更改。
但是,当一个事务写入多个分片时,并非所有外部读取操作都需要等待已提交事务的结果在所有分片上可见。例如,如果提交了一个事务,并且在分片A上可以看到写1,但是在分片B上仍然看不到写2,则外部读处于读关注状态
"local"
可以读取写1的结果而看不到写2。
从MongoDB 3.6开始,更改流可用于副本集和分片群集。更改流允许应用程序访问实时数据更改,而不会带来复杂性和拖延操作日志的风险。应用程序可以使用更改流来订阅一个或多个集合上的所有数据更改。
副本集提供了许多选项来支持应用程序需求。例如,您可以在多个数据中心中部署具有成员的副本集,或通过调整members[n].priority
某些成员的数量来控制选举的结果
。副本集还支持专用成员进行报告,灾难恢复或备份功能。
有关更多信息,请参见优先级0副本集成员, 隐藏副本集成员和 延迟副本集成员。
[1] | (1,2)在某些情况下,副本集中的两个节点可能暂时相信他们是主要的,但最多,其中一人将能够完全写入的写入关注。可以完成
写入操作的节点是当前主节点,另一个节点是以前的主节点,由于网络分区,该主节点尚未意识到其降级。发生这种情况时,尽管已请求读取首选项,但连接到前主数据库的客户端可能仍会观察到过时的数据
,并且对前主数据库的新写入最终将回滚。{ w:
"majority" } { w: "majority" } primary |