根本原因是local.system.replset表硬编码旧域名，必须确保所有节点对新域名的正反向解析一致且能telnet通；rs.reconfig()需在PRIMARY执行、version递增、host全部可解析，否则报“NodeNotFound”或“not master”。

MongoDB 副本集节点间无法通过域名通信，根本原因不是 DNS 解析慢或缓存没刷新，而是 **每个节点启动时硬编码在 local.system.replset 里的 host 字段值，必须能被其他所有节点实时、准确、一致地解析并建立 TCP 连接**。一旦某节点解析失败（哪怕只差一个字母、大小写不匹配、或 /etc/hosts 里映射成 127.0.0.1），心跳就断，状态卡在 STARTUP2 或直接被踢出集群。

rs.status() 显示旧域名但连接失败

这是最典型的误判信号：你改了 DNS 或 /etc/hosts，rs.status() 仍显示老域名，mongo --host old-name:27017 却连不上——说明副本集配置没更新，不是 DNS 问题，是 local.system.replset 表里还存着旧地址。

• 执行 rs.conf() 查看当前配置中每个成员的 host 字段，确认是否已更新为新域名
• 若未更新，必须调用 rs.reconfig()，但注意：version 必须比当前 rs.conf().version 大 1，否则直接拒绝
• 不能从 SECONDARY 节点发起 rs.reconfig()，必须连到当前 PRIMARY 再操作
• 所有新域名必须能在每个节点上执行 nslookup new-node.example.com 和 telnet new-node.example.com 27017 成功

telnet 域名端口通但 rs.initiate() 后卡在 STARTUP2

这说明网络层通了，但 MongoDB 内部校验失败。常见于：主节点自己无法反向解析新成员的域名，或解析结果与配置中写的不一致（比如配置写 node1.example.com，但主节点 nslookup node1.example.com 返回 127.0.0.1）。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 在主节点上执行 nslookup 和 ping 验证每个成员域名，确保返回的是真实 IP（非 127.0.0.1）
• 检查所有节点的 /etc/hosts 是否统一，避免 A 节点写 192.168.10.11 node1.example.com，B 节点却写 127.0.0.1 node1.example.com
• 确认 mongod 启动时绑定的 bindIp 包含该域名对应的真实网卡 IP，而非仅 127.0.0.1
• MongoDB 5.0+ 强制要求副本集成员必须用域名，禁用纯 IP；若你混用了 IP 和域名，集群无法达成法定人数（quorum）

rs.reconfig() 报 “NodeNotFound” 或 “not master”

这两个错误看似不同，根源高度重合：要么你没连对主节点，要么新配置里某个 host 值在当前节点本地根本无法解析。

• not master：说明你正在 SECONDARY 上执行 rs.reconfig()；先 rs.stepDown() 或换连到 PRIMARY
• NodeNotFound：mongod 在加载新配置前会逐个尝试解析每个 host，只要有一个失败（DNS NXDOMAIN、超时、或返回 127.0.0.1），就立刻报错退出，不会继续校验后续项
• 检查日志：grep "hostname" /var/log/mongodb/mongod.log，通常紧挨着报错行会有类似 Failed to resolve hostname 'node2.example.com' 的提示
• 临时方案：在所有节点的 /etc/hosts 中显式绑定新域名到正确 IP，比依赖 DNS 更可靠

真正容易被忽略的点是：**域名解析一致性必须贯穿整个生命周期——从 rs.initiate() 初始化那一刻起，到每个节点重启、每次 reconfig 执行、甚至故障转移后新主节点选举，所有节点看到的域名解析结果都必须完全相同**。少一次 nslookup 验证，就可能让集群在半夜降级。