shard副本集选举失败主因是投票成员数不足“大多数”，即n/2+1；常见情形包括节点宕机、仲裁节点误用、残留配置、网络分区、时钟不同步及未初始化等，需逐项排查。
shard副本集投票成员数不足“大多数”
分片节点本质是独立的副本集，选举失败最常见原因是存活投票成员数 N 不满足 N/2 + 1。比如 3 节点副本集，只要挂掉 2 个，剩下 1 个无法凑够 2 票，就卡在 STARTUP2 或 RECOVERING 状态，永远选不出主。
检查方式：连上任一 shard 节点，运行 rs.status()，重点看 members[n].stateStr 和 ok 字段；再用 rs.conf() 确认哪些成员设置了 "votes": 1、"priority": >0 —— 只有这两项都满足的才算有效投票成员。
- 新加入的节点如果没等同步完就参与投票（尤其 MongoDB 5.0 之前），可能被算作投票成员但实际不可用，人为制造“假多数”
- 误将
arbiter加进 shard 副本集：它能投票但不存数据，会稀释数据节点权重，且一旦数据节点只剩 1 个，arbiter + 它刚好凑够 2 票，但此时写入已无冗余保障 - 配置中留有已下线节点的残留条目（
host不通但仍在rs.conf()里），它仍占 1 票配额，导致实际可用票数不足
shard节点间心跳失败或网络分区
副本集靠心跳维持成员感知，若 shard 内部出现网络分区（比如机房断连、防火墙拦截 27018 端口），节点会互相标记 health: 0，各自尝试发起选举，结果谁都凑不够多数票，最终全部降为 SECONDARY 或卡在 STARTUP2。
注意：heartbeatTimeoutSecs 默认是 10 秒，不要盲目调小。在跨机房部署时设成 5 秒，反而会让延迟波动被误判为宕机，触发频繁、无效的选举震荡。
- 用
mongostat --host <shard_member>:27018</shard_member>观察netIn/netOut是否归零，确认是否真断连 - 检查各节点时间是否一致（
ntpstat），时钟漂移超 1 秒可能导致心跳校验失败 - 确保所有 shard 成员的
bind_ip绑定的是可互通的内网地址，而非127.0.0.1或公网 IP（后者常被安全组拦截）
shard副本集配置异常或未初始化
刚启动的 mongod --shardsvr 进程默认不自动初始化副本集，必须显式执行 rs.initiate()。如果跳过这步，或者 rs.initiate() 传入的配置里 _id 与启动参数 --replSet 不一致，节点会一直停留在 STARTUP 状态，无法进入选举流程。
另一个典型问题是：用 rs.reconfig() 强制更新配置时没加 {force: true}，而当前没有主节点，命令直接被拒绝，导致配置卡在旧状态。
- 确认启动命令含
--shardsvr --replSet <name></name>，且<name></name>与rs.initiate({ _id: "<name>" })</name>中的一致 - 若已有节点在
STARTUP2，先用rs.status()查看是否有成员处于ARBITER或HIDDEN状态干扰了初始视图 - 避免在 config server 尚未就绪时就初始化 shard —— mongos 启动依赖 config server 提供元数据，但 shard 本身不依赖它；不过若 config server 长期不可用，
sh.addShard()会失败，间接影响 shard 的注册可见性
仲裁节点（Arbiter）被错误加入 shard 副本集
shard 副本集里加 arbiter 是高危操作。它不存数据，却占用 1 票，等于把“故障容忍度”从 floor(N/2) 降为 floor((N-1)/2)。更麻烦的是：当真实数据节点只剩 1 个时，arbiter + 它刚好构成多数，能选出主，但这个“主”没有任何数据冗余 —— 写入成功等于单点落盘，一崩全丢。
MongoDB 官方明确建议：shard 副本集应由纯数据节点组成（"votes": 1, "priority": >0, no arbiter）；仲裁节点只应在 config server 副本集这种纯元数据场景下谨慎使用。
- 运行
rs.conf()检查每个成员的arbiterOnly字段，为true就得删 - 删除前先确保剩余数据节点 ≥ 3 个且全部健康，再用
rs.remove("<arbiter_host>")</arbiter_host> - 删完立刻
rs.reconfig()并验证rs.status().members中不再出现该节点
stateStr: "STARTUP2"），同时配置里又残留了一个已下线的旧节点，再加上网络抖动导致心跳超时——三者叠在一起，rs.status() 看起来一切正常，但就是死活选不出主。排查时得一条一条排除，不能只盯日志里的 “no primary” 报错。
