分片集群中宕机的是shard节点，实际指该shard所属副本集发生成员故障，由其内部自动选举机制恢复，mongos仅感知不可写并重连，不参与切换。
分片集群里宕机的是shard节点，不是Replica Set主节点
分片集群（Sharded Cluster）中每个 shard 本身就是一个独立的 Replica Set，不是单个 mongod 进程。所以“某个分片节点宕机”，实际指的是该 shard 所在的 Replica Set 中发生了成员故障——比如它的 Primary 挂了，或整个副本集多数节点失联。
这时你不能指望 Config Server 或 Mongos 去“切换分片”，真正起作用的是该 shard 内部的 Replica Set 自动选举机制。Mongos 只会感知到“这个 shard 当前不可写”，并在下一次路由时尝试重连或报错，它不参与、也不控制 shard 内部的主从切换。
常见错误现象：not master、node is recovering、not primary and secondaryOk() is false 等错误，往往不是 Mongos 配置问题，而是对应 shard 的 Replica Set 还没完成选举，或新 Primary 尚未被 Mongos 缓存识别。
- 检查路径：先连上出问题的 shard 的任意存活节点，运行
rs.status()，确认当前状态是PRIMARY、SECONDARY还是STARTUP2/RECOVERING - 注意
optimeDate和lastHeartbeatRecv字段，判断数据是否滞后、心跳是否中断 - 若看到多个节点卡在
STARTUP2，大概率是 oplog 不足或初始化同步失败，不是单纯“等选举”
rs.initiate() 后必须显式配置 priority 和 votes 才算可靠
默认初始化的 Replica Set（比如用 rs.initiate() 不带参数）所有节点 priority 都是 1、votes 都是 1，看似公平，实则埋雷：当网络抖动导致短暂分区，可能因票数胶着无法达成多数（majority），选举超时，整个 shard 写入阻塞。
真实生产环境必须手动调优。例如三节点 shard：
- 给两个数据节点设
"priority": 2，仲裁节点（Arbiter）设"priority": 0且"votes": 1 - 禁止把
"priority": 0的节点同时设为"votes": 0，否则它既不参选也不投票，等于少一个法定票数 - 用
rs.reconfig()更新配置时，必须加{force: true}参数（仅在 Primary 不可用时强制生效），但要注意这可能导致短暂回滚
错误示例：rs.conf() 显示某节点 votes: 0 且 priority: 0 → 它彻底退出集群决策，哪怕活着也没用。
心跳超时和选举阻塞常被忽略的两个硬限制
副本集选举不是“立刻发生”的。MongoDB 默认心跳间隔 2 秒，连续 5 次未收到响应才判定节点失联（即 10 秒），之后还需等待选举超时（默认 10 秒），整个过程理论最短也要 20 秒以上。这期间 Mongos 会持续向旧 Primary 发请求，直到缓存刷新或连接超时。
更隐蔽的问题是：如果副本集中有节点长期处于 RECOVERING 状态（比如磁盘慢、oplog 被截断、网络丢包），它仍会参与投票，但无法提供有效数据支持；一旦它投了反对票或不响应，就可能让选举卡在“未获 majority”状态。
- 用
rs.status().members[n].health检查每个成员健康值，0表示不可达，1表示正常 - 关键字段：
stateStr（状态）、uptime（在线时长）、optimeDate（最后同步时间）必须全部对齐才稳妥 - 不要依赖
rs.isMaster()返回结果做自动 failover 判断——它只反映本节点视角，不是全局视图
Config Server 和 Mongos 不处理 shard 内部故障
很多人误以为配好 Config Server 的高可用（比如三个 Config Server 做副本集），就能让整个分片集群“自动愈合”。其实 Config Server 只管元数据（chunk 分布、shard 列表、balancer 状态），它完全不干预每个 shard 内部的数据同步或主从选举。
也就是说：即使 Config Server 全部正常，只要某个 shard 的 Replica Set 卡在选举或数据不同步，那个 shard 就无法接受写入，mongos 会返回 NotPrimaryNoSecondaryOk 或直接超时。
- 验证方式：直连该 shard 的 Secondary 节点，执行
db.runCommand({isMaster: 1})，看ismaster是否为true - 切勿在 Mongos 层做“重试主节点”逻辑——驱动已内置 retrywrites，强行封装反而增加时序混乱风险
- 真正要监控的，是每个 shard 的
rs.status()输出中ok: 1且至少有一个stateStr: "PRIMARY"
复杂点在于：shard 内部的故障恢复是自治的，但 Mongos 对它的感知有延迟，而业务代码又常常把“写失败”当成永久错误来处理。这种认知错位，比配置本身更容易导致服务雪崩。
