mongodb 5.0起必须用主机名而非ip配置副本集成员，因启动时强制dns正反向解析验证；纯ip会导致“failed to resolve hostname”错误，需统一配置可解析主机名、正确设置bindip并确保版本、时间、网络全链路一致。
必须用主机名而非IP配置副本集成员
从 MongoDB 5.0 开始，仅用 10.0.0.1 这类 IP 地址配置 rs.initiate() 会导致节点启动失败，报错类似：Failed to resolve hostname: No address associated with hostname。这是因为 MongoDB 启动时会做 DNS 反向解析验证，而纯 IP 不满足要求。
实际做法是：所有节点提前配好可解析的主机名（如 mongo1.example.com），并在 /etc/hosts 或内网 DNS 中确保双向解析（正向 + 反向）都通。配置副本集时，members 数组里必须写主机名：
rs.initiate({
_id: "rs0",
members: [
{ _id: 0, host: "mongo1.example.com:27017" },
{ _id: 1, host: "mongo2.example.com:27017" },
{ _id: 2, host: "mongo3.example.com:27017" }
]
})
- 别在生产环境用
localhost或127.0.0.1—— 其他节点无法连接 - 所有节点的
/etc/hosts必须一致，避免某台解析失败导致初始化卡住 - 用
nslookup mongo1.example.com和dig -x $(hostname -i)验证正反向解析
bindIp 必须显式设为 0.0.0.0 或具体内网IP
mongod 默认只监听 127.0.0.1，副本集节点之间根本连不上。不改 bindIp 就算配置对了主机名，也会出现 Connection refused 或 SocketException: Connection reset。
正确做法是在每个节点的 /usr/local/mongodb/config/conf/mongod.conf 中明确设置：
net: port: 27017 bindIp: 0.0.0.0 # 或写具体内网IP，如 10.0.0.1
- 设
0.0.0.0时，必须配合防火墙规则（如ufw allow from 10.0.0.0/24 to any port 27017） - 严禁在公网暴露
bindIp: 0.0.0.0且未启用认证 —— 这等于裸奔 - 如果用云服务器，安全组也要放行对应内网段的 27017 端口
初始化前必须确认三件事
副本集初始化失败，90% 是因为这三项没检查清楚，而不是配置语法问题。
-
mongod进程必须已运行且无报错：用systemctl status mongodb看 Active 状态，再查/usr/local/mongodb/config/log/mongod.log最后几行有没有waiting for connections - 所有节点 MongoDB 版本严格一致：用
mongod --version对比，主版本号（如 7.0.x）必须相同，小版本差异可能导致选举异常 - 系统时间误差不能超过 1 秒：用
chronyc tracking检查 NTP 同步状态，时间不同步会导致 oplog 时间戳错乱，同步直接中断
不要用仲裁节点（Arbiter）替代数据节点
虽然 arbiterOnly: true 能凑够奇数投票数，但它不存数据、不参与读操作、不提供冗余 —— 生产环境加它只是“假高可用”。一旦 Primary 和一个 Secondary 同时宕机，剩下那个 Secondary + Arbiter 根本无法选出新 Primary（因为 Arbiter 不具备数据资格）。
真实建议：
- 至少部署 3 个数据节点（Primary + 2×Secondary），全部开启
priority和votes - 如果资源受限，宁可上 2 数据节点 + 1 延迟节点（
slaveDelay: 3600），也别用 Arbiter - 延迟节点要设
hidden: true和priority: 0，避免被应用误读
副本集不是“配齐三个节点就完事”，主机名解析、网络可达性、时钟同步、版本一致性这些底层链路，断哪一环都会让整个集群卡在初始化或选举阶段。动手前先逐节点验证连通性和日志，比反复重试 rs.initiate() 有效得多。
