分片集群高可用依赖物理拓扑设计：mongos与shard、config server须跨交换机/机架部署，避免单点故障；config server必须3节点CSRS并跨机架；shard副本集成员须分散在不同交换机；需联合验证网络策略与物理拓扑。
分片集群不是“加了分片就高可用”，物理拓扑设计不当，一台交换机宕掉可能让整个集群失联——这不是理论风险，是真实发生过的生产事故。
为什么mongos和shard之间不能共用同一台接入交换机
mongos节点必须能持续访问所有shard和config server；一旦它连接某个shard的网络路径中断（比如该shard所在机柜的上联交换机故障），mongos会将该shard标记为不可用，后续对该分片键范围的读写请求直接失败或超时。更严重的是，如果多个shard恰好部署在同一台物理交换机下，这台交换机挂掉会导致大量分片同时离线，触发chunk迁移阻塞、balancer停摆，甚至引发部分数据不可写。
- mongos本身不存储状态，但依赖实时心跳判断shard健康状况；心跳走的是TCP长连接，对网络抖动敏感
- shard以副本集形式存在，但副本集内各成员若都在同一交换机下，等于把“冗余”建在单点故障域里
- config server的元数据变更（如chunk拆分、迁移完成）需要被所有mongos及时感知，网络分区会让部分mongos看到过期路由表
config server副本集跨机架部署的硬性要求
从MongoDB 3.4起，config server必须是副本集（CSRS），且生产环境强烈要求3节点、跨物理机架（rack-aware）。因为config server一旦整体不可写，balancer停止工作，新chunk无法分裂，已有迁移卡住，集群会逐渐“僵化”。
- 三个config server节点不能在同一台交换机下，也不能在同一个机柜的同一PDU供电回路中
- 初始化时必须显式配置
members[n].priority和members[n].tags，例如{"rack":"rack1"}，便于后续结合writeConcern做机架级写确认 - mongos启动后会缓存一份config server元数据快照，但只在心跳失败后才尝试重拉；若config server集群因网络分区分裂，mongos可能长期使用错误视图
shard副本集成员的网络隔离原则
一个shard副本集（如shard1ReplSet）的Primary和Secondary绝不能共享同一台接入交换机——否则一次交换机故障就会导致整个shard逻辑下线，哪怕它内部有3个节点。
- 推荐部署模式：Primary在机房A机柜1，Secondary1在机房A机柜2，Secondary2在机房B（异地小集群场景）
- 必须关闭
slaveDelay和hidden:true等影响故障切换的配置，否则网络恢复后Secondary可能因延迟过大被跳过选举 - 使用
rs.status()检查lastHeartbeatRecv时间戳，比对各成员之间差异；若某成员与其他成员的心跳接收时间差超过10秒，说明存在隐蔽网络分区
最容易被忽略的一点：防火墙策略和ACL常按IP段配置，结果把整个机柜的MongoDB节点划到同一安全组，交换机故障时ACL同步失效，导致mongos连不上任何shard——物理拓扑和网络策略必须联合验证，不能只看服务进程是否running。
