生产环境 mongodb 副本集至少需3台物理服务器，因2节点无法满足多数派选举（1/2
生产环境 MongoDB 副本集至少需要 3 台物理服务器。
为什么不能用 2 台？
副本集依赖多数派（majority）选举机制决定主节点。3 节点副本集允许 1 个节点故障后仍能维持 2/3 的多数派，继续选出主节点并接受写入；而 2 节点在任一节点宕机后只剩 1/2，无法达成多数，整个副本集将只读，写操作全部失败。
常见错误现象：not master and slaveOk=false、应用持续报 NotPrimaryNoSecondaryOk、连接池耗尽。
- 2 节点 + 1 仲裁节点（arbiter）看似凑够 3 票，但仲裁节点不存数据，无法提供灾备能力——单台数据节点宕机即丢失全部最新数据，不满足生产级「数据可靠性」要求
- 同机多实例（如单台机器起 3 个
mongod）违反高可用前提：硬件、网络、OS 故障会同时击穿所有节点 - 云厂商的「共享宿主机」或「虚拟机共物理核」部署，若未明确隔离 NUMA/磁盘/I/O 资源，实际仍等效于单点
3 台是下限，不是推荐值
真实生产中，3 台仅够基础可用，但扛不住扩展性与运维压力：
- 备份节点需独立资源：不能把备份任务（
mongodump或 LVM 快照）跑在主节点同一台机器上，否则 I/O 打满直接拖垮服务 - 监控/审计进程（如
mongostat、Prometheus exporter）建议分离部署，避免和数据库争 CPU/内存 - 配置变更、版本升级、内核补丁等操作需滚动进行，3 节点意味着每次只能停 1 台，窗口极小，容错余量低
金融/政务类场景必须考虑跨 AZ 部署
单一机房断电或光缆被挖断是高频事件。MongoDB 官方文档明确要求：生产副本集应在至少 3 个可用区（AZ）分布节点。这意味着：
- 即使使用云服务器，也不能全选同可用区（如 AWS us-east-1a），否则违反「高可用」定义
- 跨 AZ 带来网络延迟上升（通常 1–3ms），需调优
heartbeatTimeoutSecs和electionTimeoutMillis，默认值在跨 AZ 下易触发误切换 -
rs.conf()中每个成员的host字段必须填 FQDN 或可解析的内网域名，不能写私有 IP —— 否则 DNS 故障时节点间心跳中断
真正棘手的不是数字本身，而是把「3 台」这个最小集合放进真实机房、云网络、安全组、DNS、监控告警、备份策略里跑通——任何一个环节没对齐，它就只是个理论上的副本集。
