复制集主节点¶

在复制集中，主节点是唯一能够接收写请求的节点。MongoDB在 主节点 上进行写操作，并会将这些操作记录到主节点的 oplog 中。 从节点 会将oplog复制到其本机并将这些操作应用到其自己的数据集上。

在拥有下述三个成员的复制集中，主节点将接收所有的写请求，而从节点会将oplog复制到本机并在其自己的数据集上应用这些操作。

Diagram of default routing of reads and writes to the primary.

复制集中任何成员都可以接收读请求。但是默认情况下，应用程序会直接连接到在主节点上进行读操作。阅读 复制集读选项 可以获得更多关于更改默认读请求目标的信息。

复制集最多只能拥有一个主节点。一旦当前的主节点不可用了，复制集就会选举出新的主节点。参见 复制集选举 获得更多信息。

In the following 3-member replica set, the primary becomes unavailable. This triggers an election which selects one of the remaining secondaries as the new primary.

Diagram of an election of a new primary. In a three member replica set with two secondaries, the primary becomes unreachable. The loss of a primary triggers an election where one of the secondaries becomes the new primary

[1] In some circumstances, two nodes in a replica set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with { w: "majority" } write concern. The node that can complete { w: "majority" } writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.

← 复制集成员复制集从节点 →