不能。votes设为0后节点完全不参与选举，既不投票也不计入法定人数，即使priority>0也会被MongoDB拒绝；该限制是硬性规则，优先级再高也无效。
votes设为0后节点还能参与选举吗
不能。只要 votes 为 0，该成员就完全不参与任何选举投票，也不被计入法定人数（quorum）计算。它既不会投出选票，也不会被其他节点当作有效投票方来确认自己是否达到“多数”。即使它的 priority 是 100，也毫无意义——MongoDB 会在 reconfig 阶段直接拒绝 votes: 0 且 priority > 0 的组合。
常见错误现象包括：
- 执行
rs.reconfig()后报错："non-voting member cannot have priority > 0" - 误以为“只关 votes 不动 priority”就能保留备用能力，结果新节点同步完数据却无法被提升为主节点
- 副本集只剩 2 个
votes: 1成员时，votes: 0节点看似“安全”，实则让整个集群失去容错能力（2 节点法定人数是 2，挂一个就不可写）
为什么PSA拓扑下修改votes容易失败
PSA（Primary-Secondary-Arbiter）结构中，仲裁者（arbiter）强制 votes: 1 且 priority: 0。当你试图把一个已有数据的 Secondary 改成 votes: 1，而当前配置里只有 1 个可写节点（即 Primary），MongoDB 会拒绝这次 rs.reconfig()，防止出现“单点可写 + 新投票节点加入”导致脑裂风险。
正确做法是分两步走：
- 先确保副本集中至少有 3 个
votes: 1的非仲裁节点（即去掉 arbiter 或加一个 Secondary） - 再执行
rs.reconfig()，显式设置目标成员的votes: 1和priority - 若必须保留 PSA，可改用
rs.reconfigForPSASet()（仅限 MongoDB 4.4+），但该命令要求新配置仍满足“最多 1 个可写节点”的约束
7个投票节点上限怎么绕不过去
MongoDB 硬性限制副本集最多 7 个 votes: 1 成员，超出会直接拒绝 rs.reconfig()，报错信息类似："cannot have more than 7 voting members"。这不是性能建议，而是 Raft 协议实现层面的硬限制。
实际部署中容易踩的坑：
- 扩容时盲目 add 新节点，默认
votes: 1，没检查当前投票数 - 把延迟节点（
slaveDelay）、隐藏节点（hidden: true）也设了votes: 1，挤占名额 - 误删旧节点后没清理
rs.conf()中残留的成员条目，导致_id编号空缺但votes仍计数
解决办法只有两个：要么把部分节点设为 votes: 0（同时必须 priority: 0），要么合并功能——例如用一个 hidden: true, priority: 0, votes: 0 节点同时承担备份 + 分析 + 延迟恢复三重角色。
votes和priority配错会导致只读故障
最隐蔽也最致命的问题：所有非仲裁节点都设了 priority: 0，但忘了它们默认 votes: 0（除非显式设 votes: 1）。此时整个副本集只剩 arbiter 有投票权，法定人数为 1，但 arbiter 永远不能成为 Primary ——结果就是集群永远无法选出主节点，所有写操作返回 "not master" 错误，彻底只读。
验证方式很简单：
- 运行
rs.status().members.map(m => [m.name, m.stateStr, m.votes, m.priority]) - 重点看所有
stateStr !== "ARBITER"的成员，是否至少有一个同时满足votes === 1 && priority > 0 - 注意：arbiter 的
priority必须是 0，且不能手动改votes（只能是 1）
真正难处理的从来不是怎么调 votes，而是每次改完都要立刻跑一遍 rs.status() 和 rs.printSecondaryReplicationInfo()，确认 oplog 追赶进度、投票资格、法定人数三者全部在线——这比记住数字重要得多。
