On this page
Replication
在本页面
MongoDB 中的一个“副本集”是一组维护相同数据集的mongod个进程。副本集提供了冗余和high availability,并且是所有生产部署的基础。本节介绍 MongoDB 中的复制以及副本集的组件和体系结构。本节还提供了与副本集相关的常见任务的教程。
冗余和数据可用性
复制提供冗余并增加data availability。使用不同数据库服务器上的多个数据副本,复制可提供一定程度的容错能力,以防止丢失单个数据库服务器。
在某些情况下,复制可以提供更大的读取容量,因为 Client 端可以将读取操作发送到不同的服务器。在不同数据中心中维护数据副本可以提高数据本地性和分布式应用程序的可用性。您还可以维护其他副本以用于专用目的,例如灾难恢复,报告或备份。
MongoDB 中的复制
副本集是一组维护相同数据集的mongod个实例。一个副本集包含多个数据承载节点和一个仲裁器节点(可选)。在数据承载节点中,只有一个成员被视为主要节点,而其他节点则被视为次要节点。
primary node接收所有写操作。一个副本集只能有一个主节点,该主节点能够确认具有{ w: "majority" }写关注的写;尽管在某些情况下,另一个蒙古实例可能会暂时认为自己也是主要的。 [1]主数据库在其操作日志中记录所有对其数据集的更改,即oplog。有关主节点操作的更多信息,请参见副本集主要。
secondaries复制主要数据库的操作日志,并将操作应用于其数据集,以使次要数据库的数据集反映主要数据库的数据集。如果主要节点不可用,则符合条件的辅助节点将举行选举以自行选举新的主要节点。有关次要成员的更多信息,请参见副本集次要成员。
在某些情况下(例如您有一个主服务器和一个辅助服务器,但是由于成本限制,禁止添加另一个辅助服务器),您可以选择将mongod实例添加到副本集arbiter。仲裁者参加elections,但不保存数据(即不提供数据冗余)。有关仲裁器的更多信息,请参见复制集仲裁器。
arbiter永远是仲裁者,而primary可能会下台成为secondary,而secondary可能会成为大选。
Asynchronous Replication
辅助节点异步地应用来自主节点的操作。通过在主要对象之后应用操作,即使一个或多个成员失败,集合也可以 continue 起作用。有关复制机制的更多信息,请参见副本集 Oplog和副本集数据同步。
对于从版本 3.6.11 开始的 MongoDB 3.6 部署,副本集的辅助成员现在为记录操作日志条目,所花费的时间超过了慢操作阈值。这些慢速 oplog 消息将在文本applied op: <oplog entry> took <num>ms
下的REPL组件下的diagnostic log中记录。这些慢操作日志条目仅取决于慢操作阈值。它们不取决于日志级别(系统级别或组件级别),配置级别或运行缓慢的采样率。探查器不会捕获缓慢的操作日志条目。
Automatic Failover
当主节点与集合中的其他成员的通信时间超过配置的electionTimeoutMillis
时段(默认为 10 秒)时,有资格的辅助节点将要求选举以提名自己为新的主节点。群集尝试完成新主数据库的选择并恢复正常操作。
副本集无法处理写入操作,直到选举成功完成。如果在主数据库脱机时将此类查询配置为在中学上运行,则副本集可以 continue 提供读取查询。
假设默认为副本配置设置,集群选择新的主要数据库之前的中值时间通常不应超过 12 秒。这包括将主要对象标记为unavailable并调用并完成election所需的时间。您可以通过修改settings.electionTimeoutMillis复制配置选项来调整此时间段。网络延迟之类的因素可能会延长完成副本集选举所需的时间,进而影响群集在没有主数据库的情况下可以运行的时间。这些因素取决于您的特定群集体系结构。
将electionTimeoutMillis复制配置选项从默认的10000
(10 秒)降低可以更快地检测到主要故障。但是,由于临时网络 await 时间等因素,群集可能会更频繁地进行选举,即使主节点处于其他状态也是如此。这可能导致w:1写操作的rollbacks增加。
您的应用程序连接逻辑应包括对自动故障转移和后续选举的容忍度。
3.6 版中的新功能:MongoDB 3.6 驱动程序可以一次检测到主数据库的丢失并自动重试某些写入操作,从而提供了对自动故障转移和选举的其他内置处理。
有关副本集选择的完整文档,请参见副本集选举。
要了解有关 MongoDB 的故障转移过程的更多信息,请参阅:
Read Operations
默认情况下,Client 端从主要[1]读取;但是,Client 端可以指定read preference来将读取操作发送到第二级。 Asynchronous replication表示从辅助数据库读取数据可能会返回不反映主数据库上数据状态的数据。有关从副本集读取的信息,请参见Read Preference。
在 MongoDB 中,Client 端可以在写入durable之前查看写入结果:
不管write concern为何,使用"local"或"available"的其他 Client 端 readConcern 都可以在向发布 Client 端确认写入操作之前看到写入操作的结果。
使用"local"或"available" readConcern 的 Client 端可以读取随后可能是rolled back的数据。
有关 MongoDB 的读取隔离,一致性和新近度的更多信息,请参阅阅读隔离度,一致性和新近度。
Additional Features
副本集提供了许多选项来支持应用程序需求。例如,您可以使用多个数据中心的成员部署副本集,或通过调整某些成员的members[n].priority来控制选举结果。副本集还支持用于报告,灾难恢复或备份功能的专用成员。
有关更多信息,请参见优先级 0 副本集成员,隐藏副本集成员和延迟副本集成员。
[1] | (1,2)在some circumstances中,副本集中的两个节点可能短暂地认为它们是主要节点,但是最多只能有{ w: "majority" }个写入问题来完成写入。可以完成{ w: "majority" }写入的节点是当前的主节点,另一个节点是以前的主节点,通常由于network partition而尚未识别其降级。发生这种情况时,尽管请求了读取首选项primary,但连接到先前主服务器的 Client 端仍可能会观察到过时的数据,并且对先前主服务器的新写入最终将回滚。 |