MongoDB分片集群如何实现多机房部署怎么操作-步骤和注意点

换到实际使用里，把为什么 config server 绝对不能跨机房？如果只是逐项记功能，MongoDB的实际价值并不容易看出来。、shard replica set 跨机房时如何避免 split-brain？、mongos 为什么不能跨机房部署？放到具体场景里理解，使用时会更清楚。

换到实际使用里，多机房部署 MongoDB 分片集群不是“能不能做”，而是“哪些组件必须隔离、哪些可以分散、哪些绝对不能跨机房”。放在具体场景中，mongos 不能跨机房部署，必须收敛到 config server 所在机房。核心结论：config server 必须单中心；shard replica set 可跨机房但需显式控制 priority/votes/tags；

为什么 config server 绝对不能跨机房？

放在具体场景中，跨机房部署 3 节点副本集后，一旦两机房间网络延迟抖动或短暂分区，majority commit 就会卡住 —— 表现为 sh.status() 中 config version 长期不更新、chunk 迁移 stuck 在 committed 状态、新分片无法加入。config server 是分片集群的“大脑”，所有 chunk 分配、分片元数据变更（如 sh.splitAt()、sh.moveChunk()）都依赖其 majority 写成功。

1. 错误现象：Waiting for majority commit 持续出现在 config server 日志；db.printShardingStatus() 显示 stale config version
2. 正确做法：3 个 config server 全部部署在同一机房（推荐主业务机房 A），哪怕该机房发生整体故障，也比跨机房导致元数据停滞更可控
3. 不要试图用 w:1 或 writeConcern: {w: "majority", wtimeout: 1000} 来“绕过”——这只会让元数据写入失败，触发更严重的路由不一致

hard replica set 跨机房时如何避免 split-brain？

每个 shard 本质是独立 replica set，双机房部署时默认选举逻辑无法保证故障时主节点唯一。必须手动干预投票权和优先级。

1. 设置 members[n].priority：机房 A 节点设为 2，机房 B 节点设为 1，杜绝平票
2. 禁用非主中心节点的投票权：members[n].votes = 0（例如机房 B 的所有节点），只保留读能力
3. 打标签并配合应用层读偏好：members[n].tags = {"region": "A"}，客户端连接串加 ?readPreference=primaryPreferred&readPreferenceTags=region:A
4. 关闭链式复制：settings.chainingAllowed: false，防止机房 B 节点从机房 A 的 secondary 同步，放大延迟影响

mongos 为什么不能跨机房部署？

从操作角度看，跨机房部署 mongos 后，网络延迟会导致缓存过期、路由错乱，典型表现是：mongos 本身无状态，但它每秒轮询 config server 获取最新路由表（config.shards、config.chunks）。

1. 客户端偶发 FailedToSatisfyReadPreference 或 NotMasterNoSlaveOk
2. 写请求被路由到已下线分片，返回 ShardNotFound
3. sh.status() 显示大量 stale chunk 信息，moveChunk 操作反复失败

更直接地说，解决方案只有两个：要么全部 mongos 实例部署在 config server 所在机房；更直接地说，要么应用层自行实现路由逻辑（如基于分片键哈希 + 本地缓存路由表），绕过 mongos。

多 Kubernetes 集群部署时 Operator 如何协调？

放在具体场景中，使用 MongoDB Kubernetes Operator 实现多机房部署时，Operator 本身不自动迁移资源。机房故障后必须人工介入：

1. 先执行 kubectl scale statefulset <shard-name> --replicas=0 -n <ns> 缩容故障集群所有 StatefulSet
2. 再编辑对应 MongoShardedCluster CRD，将原故障集群的 shards[n].replicas 设为 0，并在健康集群中调高其他 shards 的 replicas
3. Operator 不会自动重平衡 chunk，需后续手动触发 sh.startBalancer() 并监控 sh.getBalancerState()

更直接地说，真正容易被忽略的是：Kubernetes Service 的 DNS 解析范围。换到实际使用里，跨机房 Service 默认不跨集群解析，必须提前配置 CoreDNS 或 ExternalDNS，否则 mongos 根本连不上远端 shard 的 Pod IP。