主节点（Primary）与从节点（Secondary）

在MongoDB中，主节点（Primary）与从节点（Secondary）构成了复制集（Replica Set）的核心架构，通过数据冗余和自动故障转移实现高可用性。主节点负责处理所有写操作，而从节点通过异步复制保持数据同步，并在主节点失效时参与选举新的主节点。

主节点的角色与功能

主节点是复制集中唯一接受写操作的成员。所有客户端写入请求首先由主节点处理，随后将操作记录到oplog（操作日志）中。例如，当执行以下插入操作时：

// 连接到主节点（默认）
const db = connect("mongodb://primary.example.com:27017/mydb");
db.products.insertOne({
  name: "MongoDB Book",
  price: 49.99,
  category: "Database"
});

主节点会：

1. 将文档写入内存中的存储引擎
2. 记录操作到oplog（local.oplog.rs集合）
3. 向客户端返回写入确认

主节点还负责：

• 处理所有读请求（除非配置了读偏好）
• 维护复制集状态信息
• 协调心跳检测（默认每2秒一次）

从节点的特性与同步机制

从节点通过持续轮询主节点的oplog实现数据同步。典型同步流程如下：

1. 初始同步：新节点加入时，会克隆主节点完整数据
2. 持续复制：每秒检查主节点oplog变化
3. 应用操作：按时间顺序重放oplog中的操作

可以通过以下命令查看复制延迟：

rs.printReplicationInfo()
// 输出示例：
// configured oplog size:   19200MB
// log length start to end: 7434secs (2.07hrs)
// oplog first event time:  Thu Jan 01 2020 12:00:00 GMT+0800
// oplog last event time:   Thu Jan 01 2020 14:07:54 GMT+0800

从节点提供以下关键能力：

• 数据冗余：维护完整数据副本
• 读扩展：通过设置读偏好分担查询压力
• 灾备恢复：可作为备份源

故障转移与选举过程

当主节点不可达（默认10秒超时），从节点会发起选举。选举规则包括：

1. 优先级：配置文件中priority值高的节点优先
2. 数据新鲜度：拥有最新oplog的节点胜出
3. 投票权：votes:1的节点参与投票

选举过程示例：

// 查看节点状态
rs.status().members.forEach(m => {
  console.log(`${m.name}: ${m.stateStr}, optime: ${m.optime.ts}`);
});

// 手动触发选举（测试环境）
rs.stepDown(60)  // 主节点主动退位60秒

读写分离实践

通过设置读偏好实现查询分流：

// 从从节点读取（可能包含延迟数据）
const conn = Mongo(
  "mongodb://replica.example.com:27017/?replicaSet=myRepl&readPreference=secondary"
);

// 优先从主节点读取，失败时转到从节点
const conn2 = Mongo(
  "mongodb://replica.example.com:27017/?replicaSet=myRepl&readPreference=primaryPreferred"
);

需要注意：

• 从节点数据可能存在延迟（通常<1秒）
• 聚合操作可能需要$readPreference提示
• 事务必须路由到主节点

配置示例与监控

典型三节点复制集配置：

// rs.initiate() 配置
{
  _id: "myRepl",
  members: [
    { _id: 0, host: "mongo1:27017", priority: 3 },
    { _id: 1, host: "mongo2:27017", priority: 2 },
    { _id: 2, host: "mongo3:27017", priority: 1, arbiterOnly: true }
  ],
  settings: {
    heartbeatIntervalMillis: 2000,
    electionTimeoutMillis: 10000
  }
}

关键监控指标：

• 复制延迟（rs.printSlaveReplicationInfo()）
• 节点状态（rs.status()）
• Oplog窗口时间（db.getReplicationInfo()）

特殊节点类型

除标准从节点外，还存在：

隐藏节点：

{ _id: 3, host: "mongo4:27017", priority: 0, hidden: true }

用途：专用备份或报告节点，对客户端不可见

延迟节点：

{ _id: 4, host: "mongo5:27017", priority: 0, slaveDelay: 3600 }

用途：防止人为错误，提供1小时前的数据快照

仲裁节点：

{ _id: 5, host: "mongo6:27017", arbiterOnly: true }

用途：仅参与投票，不保存数据

数据一致性考量

MongoDB提供多种写关注（Write Concern）级别：

// 等待数据复制到1个从节点
db.orders.insertOne(
  { item: "laptop", qty: 1 },
  { writeConcern: { w: 2 } }
);

// 超时设置
db.products.updateOne(
  { sku: "XYZ123" },
  { $inc: { stock: -1 } },
  { writeConcern: { w: "majority", wtimeout: 5000 } }
);

一致性权衡：

• w:1：默认，仅主节点确认
• w:"majority"：确保数据持久化
• wtimeout：避免长时间阻塞

性能优化策略

针对主从架构的优化建议：

1. Oplog大小调整：

// 启动时指定oplog大小（MB）
mongod --replSet myRepl --oplogSize 20480

2. 索引策略：

• 从节点可添加不同索引满足特定查询
• 隐藏索引避免影响主节点性能

3. 网络优化：

• 专用心跳网络（settings.heartbeatMultiplier）
• 压缩复制流量（networkMessageCompressors）

典型问题排查

常见问题处理模式：

复制延迟高：

1. 检查从节点负载（db.currentOp()）
2. 验证网络延迟（ping/traceroute）
3. 评估oplog大小是否充足

选举频繁：

// 修改选举超时（需所有节点重启）
cfg = rs.conf()
cfg.settings.electionTimeoutMillis = 20000
rs.reconfig(cfg)

主节点卡顿：

• 检查写关注级别是否过高
• 分析锁竞争（db.serverStatus().locks）
• 验证存储引擎性能