4. 集群架构验收

集群架构验收不是简单确认“节点都起来了”，而是要回答三个问题：角色是否按设计分布、故障时能否正确选举、读写语义是否与业务要求匹配。副本集与分片集群在这三点上的检查对象不同，验收时必须分开处理。

一、副本集：角色、选举与读写关注

副本集由 Primary、Secondary 和 Arbiter（可选）组成。Primary 承接写操作并记录 oplog，Secondary 通过复制 oplog 保持数据同步，Arbiter 只参与投票、不持有数据。验收时先执行 rs.status()，确认每个成员的 stateStr 与设计一致，并检查 health 是否为 1、syncSourceHost 是否指向合理上游。

选举机制的核心是“多数派投票”。设副本集有 N 个有投票权成员，法定票数为 floor(N/2)+1。例如 3 成员副本集需要 2 票，5 成员需要 3 票。当 Primary 不可达时，Secondary 发起选举，获得多数票者成为新 Primary。验收要重点确认：settings 中 priority 是否让预期节点优先当选，votes 是否为 1，是否存在“偶数节点 + 无 Arbiter”导致票数分散的风险。

读写关注决定一致性与可用性的平衡。写关注 w:1 只要求 Primary 确认，延迟低但故障时可能回滚；w:"majority" 要求多数节点确认，能抵抗主节点故障；j:true 进一步要求写入 journal 后才确认。读关注 readConcern:"local" 读取当前节点最新数据，可能读到回滚数据；"majority" 只返回已被多数确认的数据；"linearizable" 保证读到最新已确认写，但延迟最高。验收时应核对业务集合的默认写关注与关键读路径是否匹配。

// 示例：检查副本集配置与选举相关字段
rs.conf().members.forEach(m => print(m._id, m.host, m.priority, m.votes));
rs.status().members.forEach(m => print(m.name, m.stateStr, m.health));

// 示例：设置默认写关注为多数派并落盘
db.adminCommand({
  setDefaultRWConcern: 1,
  defaultWriteConcern: { w: "majority", j: true },
  defaultReadConcern: { level: "majority" }
});

二、分片集群：组件角色与数据分布

分片集群由 mongos、config server 副本集和多个 shard 副本集组成。mongos 负责路由，本身不存数据；config server 保存集群元数据，必须是副本集；每个 shard 通常是独立副本集。验收时先确认 sh.status() 中所有 shard 状态为可用，再检查分片键与数据分布。

分片键决定数据如何切分。范围分片适合范围查询，但容易产生热点；哈希分片分布均匀，但范围查询会广播到所有分片。验收要检查：分片键是否具备高基数、是否单调递增、是否覆盖常用查询条件。若发现某个 shard 的 chunk 数量远高于其他 shard，说明存在分布倾斜，需要评估分片键或进行 split、moveChunk 调整。

三、架构合理性检查要点

• 节点数量与容灾：生产副本集建议至少 3 个有投票权成员，跨机架或跨可用区部署，避免单点故障。
• 选举优先级：优先节点 priority 应高于其他成员，但不要所有节点相同，否则选举结果不确定。
• 读写关注一致性：核心交易类集合建议 w:"majority" + readConcern:"majority"；日志类可放宽到 w:1。
• 分片均衡：检查各 shard 的 chunk 数与数据量差异，必要时启用 balancer 并观察迁移。
• config server 高可用：必须为副本集，且与 shard 分开部署，避免资源争抢。

完成上述检查后，建议形成一份验收记录：记录副本集成员角色与优先级、选举测试结果、读写关注配置、分片键与 chunk 分布。若发现角色与设计不符、选举无法在预期时间内完成、读写关注与业务要求不匹配、或分片分布严重倾斜，应判定为架构验收不通过，并在整改后重新验证。