rs.reconfig报“Quorum check failed”等错误的直接原因是配置中host不可达或旧IP残留导致仲裁失败；须确保端口连通、版本递增、优先更新配置再操作，并同步DNS、驱动缓存与防火墙。
rs.reconfig 报错 “Quorum check failed” 或 “Node not reachable”
直接原因：新配置里某个 host 地址不可达，或旧节点还在用原IP尝试通信，导致多数派无法形成。MongoDB 不会自动探测网络连通性，它只按 members[n].host 字段发起连接，失败就卡在投票阶段。
实操建议：
- 先确保所有节点（包括要下线的旧IP节点）能用新IP互相 telnet 通
27017端口——不是 ping，是端口连通性 - 临时把变更节点设为
priority: 0和votes: 0，避免它参与选举干扰仲裁 - 用
rs.status()确认当前 config version 和term，新配置的version必须比当前大 1，term不能降级 - 不要在 primary 上直接改自己的
host；先把它降为 secondary（rs.stepDown()），再 reconfig
修改 members[n].host 后 rs.reconfig 被拒绝：”replSetReconfig old config version too old”
本质是配置版本冲突：你读出来的旧配置已被其他节点更新过，rs.reconfig() 要求原子性，不允许基于过期快照覆盖。
实操建议：
- 每次操作前都重新执行
rs.conf()拿最新配置，别复用之前存的变量 - 编辑时只改目标节点的
host字段，不动_id、votes、priority等其他字段（除非你明确要调） - 如果集群有隐藏节点或延迟节点，它们也必须出现在新配置里，哪怕只是
host更新了——遗漏会导致校验失败 - 用
rs.reconfig(newConf, {force: true})是危险操作，仅当 primary 已彻底失联且你确认其他节点数据一致时才考虑
变更后 secondary 启动报错 “No host described in new configuration X for replica set Y”
这是启动时加载的 mongod.conf 里 replication.replSetName 和实际配置中 _id 不匹配，或者该节点没被包含在新 members 数组里。
实操建议：
- 检查该节点的配置文件，确认
replication.replSetName和rs.conf()._id完全一致（大小写、下划线都不能错） - 确认
rs.conf().members中每个_id都对应一个真实运行中的节点，且host可解析（DNS 或 /etc/hosts 要同步更新） - 如果节点曾被临时移除，现在要加回，不能只改
host，得用rs.add({host: "new.ip:27017", _id: N})显式加入，再 reconfig - systemctl restart mongod 前，先用
mongod --config /etc/mongod.conf --replSet yourRS --port 27017 --bind_ip_all手动试启，看日志里是否还有 host 解析失败
IP 变更后应用连接中断，但 rs.status() 显示 all members are STARTED
集群内部通信恢复了，但客户端驱动还在用旧 connection string 缓存 DNS 或直连 IP，不会自动刷新 replica set 的拓扑信息。
实操建议：
- 客户端连接字符串里的 seed list 必须包含至少一个**始终可用**的新IP节点，不能全写旧IP
- Java 驱动需设
heartbeatFrequencyMS=10000（默认 10s），Node.js 驱动要开useUnifiedTopology: true，否则拓扑发现慢甚至卡死 - 别依赖 DNS 轮询——MongoDB 驱动不支持 SRV 记录自动重载，/etc/hosts 改了也要重启应用进程
- 验证方式：在应用侧打日志输出
client.topology.description.servers（Node.js）或cluster.getDescription().getServerDescriptions()（Java），确认看到的是新IP
