MongoDB 3.2 副本集：成员角色、选举与读写一致性

MongoDB 副本集通过在多个成员中保存同一组数据，在主节点不可用时选举新的主节点。它主要提供冗余和故障转移；分片则用于将数据分布到不同分片，两者可以组合，但不能混为一谈。

角色与多数票

Primary 接受普通写入，Secondary 复制并应用变化。符合条件的成员参与选举；Arbiter 只投票、不保存业务数据，因此不能充当数据副本。仲裁节点也不是独自决定谁当主节点，而是参与选举协议。

学习环境可以使用一主一从加仲裁的结构，但它只有两份数据。是否采用仲裁节点，要综合数据冗余、写关注和故障域考虑；不能认为三台机器就等于三份可恢复数据。

配置并初始化

下面展示 MongoDB 3.2 系列的 YAML 配置结构，主机路径按实际环境填写：

storage:
  dbPath: /path/to/data
systemLog:
  destination: file
  path: /path/to/mongod.log
  logAppend: true
net:
  bindIp: 127.0.0.1
  port: 27017
replication:
  replSetName: demo-rs

回环绑定只适合本机学习。跨主机时，要让成员使用相互可达的地址，并为每个进程准备独立目录。启用成员认证时，各节点的 keyFile 内容要匹配，路径和文件权限正确；账户引导按对应版本的 localhost exception 与认证流程执行，不能用拼错的 auth 参数碰运气。

使用对应版本的 mongo shell，在一个成员上以规划好的成员配置执行 rs.initiate，再用 rs.status() 查看角色和健康状态。应用连接串应提供副本集名称和可发现的成员地址，不能只永久绑定某个当时的主节点。

读偏好不保证读到最新数据

Secondary 并非不提供服务，它持续参与复制，也可以在允许的读偏好下服务查询。副本可能落后，读写关注、会话及应用一致性要求要一起考虑；开启从节点读取不意味着所有查询自动被均匀分流。

在隔离环境验证主节点停止、选举、客户端重连和恢复追赶，并检查所选 write concern 在故障下的行为。使用服务管理器或授权的 shutdown 命令正常停止进程，避免把强制结束进程作为常规维护方式。

参考：副本集、仲裁节点。