因为单节点config server无法满足元数据高可用和选举容错要求，MongoDB 3.4+强制其必须为副本集（CSRS），否则mongos启动即报错退出，且集群将完全失能。
为什么 MongoDB 3.4+ 的 config server 必须是副本集？
因为单节点 config server 无法满足元数据高可用和选举容错的基本要求。从 MongoDB 3.4 开始，官方强制要求配置服务器（config server）必须部署为副本集（CSRS，Config Server Replica Set），不再支持单节点或主从模式。
核心原因只有一个：mongos 启动时会从 config server 加载路由元数据（如分片键范围、chunk 分布、shard 映射等），而这些数据一旦写入就绝不允许丢失或不一致。单点 config server 故障会导致整个分片集群“失明”——mongos 无法获知数据在哪，所有读写请求直接失败，且无法自动恢复。
单节点 config server 会触发什么错误？
启动 mongos 时若连接的是单节点 config server，会立即报错退出：
error: couldn't connect to server [config_host:port] (127.0.0.1), connection attempt failed: InvalidOptions: Config server must be a replica set
这个错误不是警告，而是硬性拒绝启动。即使你用旧版 MongoDB（如 3.2）成功跑过单节点 config server，升级到 3.4+ 后也必须重构为副本集，否则集群无法启动。
CSRS 要求至少三个节点？
不，CSRS 最小规模是 三个节点，但其中可以包含仲裁节点（arbiter）来降低成本。实际部署中常见组合是：
- 两个数据节点 + 一个仲裁节点（
priority: 0,votes: 1）——节省磁盘和内存，适合中小集群 - 三个全功能数据节点——更健壮，支持多数派写入确认（
w: "majority"） - 严禁使用偶数个数据节点（如 2 或 4 个）且无仲裁节点，否则选举可能卡在“平票”状态
注意：keyFile 和 replSet 名称（如 configRepl）必须在所有 config server 节点上严格一致，且不能与 shard 的副本集名称重复。
为什么不能把 config server 和 shard 副本集混用？
可以物理共存，但逻辑上必须隔离。每个 config server 节点只能属于且仅属于一个副本集（即 configRepl），不能同时加入某个 shard 的副本集（如 shard01）。否则会出现：
-
mongod启动失败，提示already initialized as part of another replica set - 心跳检测混乱，导致 config server 间状态不同步
- chunk 迁移过程中元数据写入失败，引发
StaleConfig错误
真实生产环境中，config server 应该独立部署，避免与 shard 或 mongos 共享机器——哪怕只是临时测试，也容易因资源争抢导致元数据更新延迟，进而触发连锁故障。
