MongoDB复制集通过多节点冗余来保障数据高可用，但不同节点的职责差异极大。Primary节点是唯一可接收写操作的成员，所有数据变更都会先记录在本地oplog中，再异步推送给其他节点。Secondary节点保存完整数据副本，通过拉取Primary的oplog实现同步，平时可以承接读请求，当Primary失效时具备被选为新Primary的资格。Arbiter是一个特殊的轻量级节点，它不存储任何业务数据，仅仅在选举过程中投出关键一票，用来打破平局或凑足多数派。理解这三种角色的定位，是设计稳定集群的第一步。
Primary节点的写机制与选举逻辑
Primary在复制集中处于核心地位，客户端只有通过它才能执行insert、update、delete等写命令。每当发生数据修改，Primary会将该操作以幂等格式写入oplog集合，随后Secondary节点通过长轮询方式获取这些日志并在本地重放。这种机制决定了Primary的负载通常高于其他节点，因此在生产环境中应为其分配更好的磁盘与CPU资源。
当复制集初始化或当前Primary宕机时，剩余节点会触发选举。选举基于Raft-like协议，各节点比较自身数据新鲜度（通过optime与选举任期）以及优先级配置。只有获得多数票（大于节点总数一半）的节点才能成为Primary。若集群节点数为偶数，或过多节点不可用导致无法形成多数派，选举将失败，集群进入只读状态。这也是为什么Arbiter常被引入的原因。
我们可以通过配置文件显式设定节点优先级，例如将性能更强的机器优先级调高，使其更有可能在选举中胜出。下面是一段典型的复制集节点配置片段，其中priority字段控制了选举倾向：
// 复制集配置示例
var cfg = {
_id: "rs0",
members: [
{ _id: 0, host: "192.168.0.1:27017", priority: 2 },
{ _id: 1, host: "192.168.0.2:27017", priority: 1 },
{ _id: 2, host: "192.168.0.3:27017", arbiterOnly: true }
]
};
rs.reconfig(cfg);
Secondary节点的数据同步与读扩展能力
Secondary的核心价值在于提供数据冗余与读能力扩展。它持续从Primary（或就近的其他Secondary）拉取oplog，并在本地严格按顺序应用，从而保证最终一致性。根据网络与负载状况，Secondary可能存在秒级甚至更长的复制延迟，因此在将读请求路由到Secondary时，应用层必须容忍这种滞后。MongoDB提供了readPreference策略，可让驱动把部分查询发往Secondary以分担主节点压力。
除了普通Secondary，还存在隐藏节点（hidden）和延迟节点（delayed）等变体。隐藏节点不参与读分布但计入选举票数，延迟节点会故意落后一段时间以便从误删除中恢复。下面的表格对比了几种Secondary的常见属性：
| 节点类型 | 存储数据 | 可读 | 可选举 | 典型用途 |
|---|---|---|---|---|
| 普通Secondary | 是 | 是 | 是 | 读扩展、故障转移 |
| 隐藏Secondary | 是 | 否 | 是 | 专用备份、报表 |
| 延迟Secondary | 是 | 否 | 否 | 防误删恢复 |
在运维中，我们经常需要检查Secondary的同步状态。使用rs.status()命令可以观察到每个成员的optimeDate与stateStr，进而判断是否存在异常延迟。若发现某个Secondary长期落后，应排查其磁盘IO或网络带宽是否成为瓶颈。
Arbiter节点的利弊与部署注意事项
Arbiter的设计初衷是用极低资源开销解决选举平局问题。它不写数据、不响应业务查询，仅维护一个最小的配置与投票功能。在双机房场景中，若每边各放一个数据节点，当链路中断时两边都无法凑齐多数派，此时在第三方位置部署一个Arbiter就能让某一侧顺利选出Primary。从成本角度看，Arbiter可部署在配置很低的机器甚至容器里。
然而滥用Arbiter会埋下隐患。由于Arbiter不存数据，如果集群由一个Primary、一个Secondary和一个Arbiter组成，一旦Secondary挂掉，只剩Primary与Arbiter，虽然能维持多数派继续写入，但已无任何数据冗余；若此时Primary也故障，Arbiter无法提供数据，服务将完全中断且可能需人工介入。因此官方建议尽量使用奇数个数据节点，Arbiter只作为补充而非替代。
部署Arbiter时需将其arbiterOnly设为true，并且不要把它和Primary放在同一故障域。以下命令演示了如何向已有复制集添加Arbiter：
// 向复制集rs0添加Arbiter节点
rs.addArb("192.168.0.4:27017");
// 查看当前配置确认arbiterOnly标记
printjson(rs.conf().members);
综合来看，Primary、Secondary与Arbiter在MongoDB复制集中各司其职。合理搭配三者比例、明确故障域隔离，才能在保证写可用性的同时控制硬件投入。对于大多数生产系统，采用三数据节点或三数据节点加一Arbiter的拓扑，往往比单纯依赖Arbiter更加稳健。
MongoDBreplica_setarbiter_node修改时间：2026-08-18 04:28:27