config server必须单中心部署，因其元数据写入依赖majority commit，跨机房网络抖动会导致chunk迁移卡住、config version停滞；shard replica set可跨机房但需显式配置priority/votes/tags防split-brain；mongos须与config server同机房，否则路由表过期引发写入错误和查询失败。
多机房部署 MongoDB 分片集群不是“能不能做”，而是“哪些组件必须隔离、哪些可以分散、哪些绝对不能跨机房”。核心结论：config server 必须单中心；shard replica set 可跨机房但需显式控制 priority/votes/tags；mongos 不能跨机房部署，必须收敛到 config server 所在机房。
为什么 config server 绝对不能跨机房？
config server 是分片集群的“大脑”，所有 chunk 分配、分片元数据变更（如 sh.splitAt()、sh.moveChunk()）都依赖其 majority 写成功。跨机房部署 3 节点副本集后，一旦两机房间网络延迟抖动或短暂分区，majority commit 就会卡住 —— 表现为 sh.status() 中 config version 长期不更新、chunk 迁移 stuck 在 committed 状态、新分片无法加入。
- 错误现象：
Waiting for majority commit持续出现在 config server 日志；db.printShardingStatus()显示stale config version - 正确做法：3 个 config server 全部部署在同一机房（推荐主业务机房 A），哪怕该机房发生整体故障，也比跨机房导致元数据停滞更可控
- 不要试图用
w:1或writeConcern: {w: "majority", wtimeout: 1000}来“绕过”——这只会让元数据写入失败，触发更严重的路由不一致
shard replica set 跨机房时如何避免 split-brain？
每个 shard 本质是独立 replica set，双机房部署时默认选举逻辑无法保证故障时主节点唯一。必须手动干预投票权和优先级。
- 设置
members[n].priority：机房 A 节点设为2，机房 B 节点设为1，杜绝平票 - 禁用非主中心节点的投票权：
members[n].votes = 0（例如机房 B 的所有节点），只保留读能力 - 打标签并配合应用层读偏好：
members[n].tags = {"region": "A"}，客户端连接串加?readPreference=primaryPreferred&readPreferenceTags=region:A - 关闭链式复制：
settings.chainingAllowed: false，防止机房 B 节点从机房 A 的 secondary 同步，放大延迟影响
mongos 为什么不能跨机房部署？
mongos 本身无状态，但它每秒轮询 config server 获取最新路由表（config.shards、config.chunks）。跨机房部署 mongos 后，网络延迟会导致缓存过期、路由错乱，典型表现是：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 客户端偶发
FailedToSatisfyReadPreference或NotMasterNoSlaveOk - 写请求被路由到已下线分片，返回
ShardNotFound -
sh.status()显示大量 stale chunk 信息，moveChunk操作反复失败
解决方案只有两个：要么全部 mongos 实例部署在 config server 所在机房；要么应用层自行实现路由逻辑（如基于分片键哈希 + 本地缓存路由表），绕过 mongos。
多 Kubernetes 集群部署时 Operator 如何协调？
使用 MongoDB Kubernetes Operator 实现多机房部署时，Operator 本身不自动迁移资源。机房故障后必须人工介入：
- 先执行
kubectl scale statefulset <shard-name> --replicas=0 -n <ns>缩容故障集群所有 StatefulSet - 再编辑对应
MongoShardedClusterCRD，将原故障集群的shards[n].replicas设为0，并在健康集群中调高其他 shards 的replicas - Operator 不会自动重平衡 chunk，需后续手动触发
sh.startBalancer()并监控sh.getBalancerState()
真正容易被忽略的是：Kubernetes Service 的 DNS 解析范围。跨机房 Service 默认不跨集群解析，必须提前配置 CoreDNS 或 ExternalDNS，否则 mongos 根本连不上远端 shard 的 Pod IP。
