rs.reconfig() 会触发主节点主动降级以启动选举，这是保障一致性的设计行为；修改 priority、hidden 等软配置可热更新，但增删节点或改 host 会导致 invalidreplicasetconfig 错误。
rs.reconfig() 会触发主节点降级，这是设计行为，不是 bug
直接调用 rs.reconfig() 修改副本集配置（比如增删节点、调整 priority、votes 或 hidden）时，MongoDB 要求新配置必须通过多数节点投票确认。为保证一致性，当前主节点会主动退位（step down），触发一次选举——这意味着写入会短暂中断（通常几秒），但整个副本集无需重启。
常见错误现象：not master 或 NotMasterNoSlaveOk 错误在执行后立刻出现，是正常响应，说明主已降级；客户端若未正确处理重试或自动重连，可能报错超时。
- 必须在当前主节点上执行，否则报错
not master - 新配置中
_id字段必须与现有成员完全一致（不能改 host/port，只能改元数据） - 修改
members[n].host是非法的，会导致InvalidReplicaSetConfig: host must match existing member - 如果新配置不满足多数原则（如从 3 节点改成 2 节点且都在线），
rs.reconfig()会直接拒绝并报错
如何安全修改 priority、hidden、tags 等可热更新字段
这类字段不改变拓扑结构，属于“软配置”，只要确保新配置合法且能被多数节点接受，就可以在线生效。关键在于避免意外触发不必要的选举或分裂。
使用场景：把某节点设为隐藏（hidden: true）、降低备用节点优先级（priority: 0）、添加读负载标签（tags: { "region": "us-east" }）等。
- 先用
rs.conf()拿到当前配置，深拷贝一份再改，避免引用污染 - 只修改目标成员对象里的字段，不要动
version——驱动会自动递增；手动设低版本会报OlderConfiguration - 对
priority做非零调整时，确认该节点有资格参选（votes: 1且hidden: false），否则可能长期无法成为主 - 修改
tags后需配合 readPreference 使用，单靠改 tags 不影响路由，只是提供筛选依据
rs.reconfig({force: true}) 是危险操作，仅限紧急恢复
当副本集卡在无法达成多数的状态（例如只剩一个节点在线，但你急需让它临时当主），可以用 force: true 强制应用配置。但它绕过多数确认，破坏数据一致性保障。
典型错误现象：强制 reconfig 后其他节点重新加入时拒绝同步，报 Our replica set configuration is stale 或回滚失败。
- 只应在所有其他节点彻底不可达、且你明确接受潜在数据丢失风险时使用
- 执行后必须尽快恢复多数节点，并用
rs.reconfig()（无 force）重新同步最新配置 - 永远不要在生产环境常规运维中使用
force: true，它不是“跳过检查”的快捷键 - 执行前务必确认该节点的 oplog 足够新，否则恢复后可能因缺少增量而全量 resync
修改 arbiterOnly 或 buildIndexes 需要特别注意兼容性
这两类字段控制节点角色和索引行为，虽然也属热更新范畴，但 MongoDB 版本间表现不同。4.2+ 对 arbiterOnly 更严格，而 buildIndexes: false 在某些版本会影响复制线程初始化。
使用场景：将普通节点转为仲裁节点（节省资源），或禁用从节点建索引（避免 I/O 冲突）。
-
arbiterOnly: true只能在votes: 1的节点上设置，否则启动时报错；已有的数据节点不能直接改为仲裁节点，必须先移除再以 arbiter 身份重新添加 -
buildIndexes: false设为 true 后，该节点不会再为任何集合建索引（包括系统集合），但已有索引不受影响 - 4.4+ 开始，
buildIndexes: false节点默认不参与初始同步（initial sync）的索引构建阶段，需确认业务是否依赖其上的查询性能 - 修改后建议观察
rs.status().members[n].stateStr是否稳定为ARBITER或SECONDARY，而非反复震荡
rs.reconfig() 成了暴露底层状态的探针。
