不能。priority: 0 的节点自动失去投票资格，votes 值被强制重置为 0，该设置是硬性规则，优先级为 0 是参与选举的第一道开关，votes 仅对 priority > 0 的节点有效。

只读节点设 priority: 0 后还能投票吗？

不能。MongoDB 中，priority: 0 的节点自动失去投票资格，无论 votes 字段是否显式设为 1。这是硬性规则：优先级为 0 → 投票权被强制忽略，votes 值直接失效。

常见错误现象是：在副本集配置里把 votes: 1 和 priority: 0 一起写，以为“我授权它投票，只是不抢主”，结果 rs.conf() 查看时发现该节点的 votes 字段被 MongoDB 自动重置为 0，且日志里出现 Member with priority 0 cannot have votes > 0 警告。

• priority 是决定能否参与选举的**第一道开关**，值为 0 就直接退出投票流程
• votes 只对 priority > 0 的节点有意义，仅用于调节票数权重（如设为 2）
• 修改配置必须用 rs.reconfig()，且需在主节点执行；直接改文档或绕过校验会失败

想让节点只读又保留投票权，该怎么配？

唯一合法方式是保持 priority > 0，同时用 slaveDelay 或 hidden: true 实现逻辑只读，而非靠 priority: 0。

使用场景典型的是灾备节点：需要参与选主保障高可用，但不允许应用直连读取（避免拖慢主库或读到延迟数据）。这时不能关 priority，而应组合其他属性：

• 设 priority: 0.5（非整数合法，且低于默认 1.0，降低当选概率）
• 加 hidden: true，让它不出现在 mongos 或客户端种子列表中，自然无法被读
• 或设 slaveDelay: 3600，制造一小时延迟，应用层通常不会连这种节点
• 务必同步设 votes: 1（默认就是 1，但显式写上更稳妥）

rs.reconfig() 重配时容易踩的坑

重配只读节点的副本集配置不是原子操作，稍有不慎会导致整个副本集短暂不可用，甚至触发意外选举。

常见错误现象包括：NotMaster 错误持续数十秒、新配置未生效、节点状态卡在 STARTUP2。

• 执行前必须确认当前主节点健康，且 rs.status().members[n].stateStr === "PRIMARY"
• 不要在重配时修改多个节点的 priority，尤其避免把所有 >0 的节点 priority 全设成 0 —— 这会导致无节点可参选
• 配置对象里必须包含完整 members 数组（不能只传要改的那个节点），否则缺失成员会被删掉
• 加 force: true 参数仅限主挂了、强制恢复场景，日常配置严禁使用

为什么 MongoDB 不允许 priority: 0 却 votes: 1？

设计上，priority 不单是“竞选意愿”，更是节点是否具备**实时参与共识**能力的信号。Priority 0 表示“我不参与任何决策流程”，包括投票、提交 oplog、接受心跳响应等底层行为。强行给它投票权，会破坏 Raft 类协议的安全边界。

性能与兼容性影响很小，但语义冲突极大：4.4+ 版本会静默覆盖 votes；3.6 以前可能报错拒绝加载配置。真正容易被忽略的是——这个限制不体现在 shell 提示里，只藏在日志和 rs.conf() 返回结果中。

如果你正在调试一个“明明写了 votes:1 却投不了票”的节点，先 rs.conf().members[n].priority 看一眼，90% 是这里卡住的。