4. 分片集群架构与容灾挑战
单机或副本集备份恢复的核心对象是“一个数据目录 + 一份 oplog”，而分片集群（Sharded Cluster）把数据、元数据和路由入口拆成了三类角色，备份恢复的对象从“一个整体”变成了“一组相互依赖的组件”。理解这三类角色的职责边界，是判断“该备份什么、能恢复到什么程度、故障时先救谁”的前提。
三类角色的职责与依赖关系
分片集群由三种进程组成，它们各自持有不同性质的数据：
- mongos（路由进程）：无状态，不持久化业务数据。它接收客户端请求，向 config server 查询分片键到分片的映射（chunk 分布），再把请求转发到对应 shard，并负责跨分片查询的归并排序。因为无状态，mongos 本身不需要备份，重启或扩容即可，但它的配置（如连接串、启动参数）需要纳入配置管理。
- config server（配置服务器）：以副本集形式部署（CSRS），存储集群的元数据——分片列表、数据库与集合的分片信息、chunk 范围与分布、均衡器状态、集群参数等。它体量小，但一旦丢失或与 shard 数据不一致，整个集群的路由就会错乱，是恢复时最关键的“地图”。
- shard（分片）：每个 shard 是一个副本集，实际存储业务数据。分片集群的数据被切分成 chunk 分散在各 shard 上，单个 shard 只持有全局数据的一个子集。因此单独恢复某一个 shard 没有意义，必须保证所有 shard 恢复到同一个逻辑时间点。
三者的依赖方向是：客户端 → mongos → config server（取路由）→ shard（取数据）。恢复时依赖方向反过来：先恢复 config server 与各 shard 到一致时间点，再启动 mongos 对外提供服务。
分片集群备份恢复的特殊性
与副本集相比，分片集群的备份恢复有四个绕不开的难点：
- 一致性时间点难以对齐。各 shard 是独立副本集，备份工具在不同 shard 上启动备份的时刻天然存在偏差。如果 shard01 恢复到 T1、shard02 恢复到 T2，而 T1 与 T2 之间恰好发生了 chunk 迁移，就会出现“数据在 shard01 上、元数据却指向 shard02”的错位。因此必须使用支持集群级一致性快照的机制，例如 MongoDB 的
db.fsyncLock()配合快照，或 Atlas/Cloud Manager 的集群级备份，让所有 shard 与 config server 落在同一逻辑时间点。 - 元数据与数据必须成对恢复。config server 中的 chunk 映射是“地图”，shard 中的数据是“地形”。只恢复数据不恢复元数据，mongos 无法正确路由；只恢复元数据不恢复数据，路由会指向不存在的数据。两者必须来自同一备份批次。
- 不能按单 shard 做点恢复。副本集可以用 oplog 做任意时间点恢复（PITR），但分片集群的 PITR 需要所有 shard 的 oplog 都回放到同一时间戳，且 config server 的元数据也要回放到该时间戳。任何单个 shard 的 oplog 缺失或断裂，都会导致集群级 PITR 失败。
- 恢复后需要校验路由完整性。恢复完成后不能直接放流量，应先启动 config server 与 shard，再启动 mongos，然后用
sh.status()、db.collection.getShardDistribution()检查 chunk 分布是否与预期一致，并抽样验证跨分片查询结果。
常见故障场景与应对
分片集群的故障往往不是“单点挂了”这么简单，而是角色之间的依赖被打破。以下场景在工程中高频出现：
| 故障场景 | 表现 | 影响范围 | 应对要点 |
|---|---|---|---|
| config server 副本集多数节点不可用 | mongos 无法刷新路由表，新请求报路由错误 | 整个集群不可写，已有连接可能短暂可用 | 优先恢复 CSRS 多数派；若元数据损坏，用最近一次集群级备份恢复 config server |
| 单个 shard 副本集主节点故障 | 该 shard 自动选主，期间该分片读写短暂失败 | 仅影响落在该 shard 的 chunk | 等待自动选主；若副本集整体不可用，需从该 shard 备份恢复，但必须与其他 shard 时间点对齐 |
| chunk 迁移过程中备份 | 备份快照中 chunk 同时存在于源和目标，或都不存在 | 恢复后出现数据重复或丢失 | 备份前暂停均衡器（sh.stopBalancer()），备份完成后再开启 |
| 误删集合或误更新 | 业务发现数据异常，需要回退到故障前时间点 | 取决于集合是否分片及影响范围 | 集群级 PITR 到误操作前时间戳；若未开启 PITR，只能恢复到最近全量备份点 |
| mongos 配置丢失或版本不匹配 | 客户端连接失败或路由行为异常 | 接入层不可用 | mongos 无状态，按标准配置重新部署即可，但需保证与 config server、shard 版本兼容 |
易错点：很多团队把分片集群当成“多个副本集”分别备份，恢复时也分别恢复。这种做法在 chunk 未发生迁移时可能侥幸成功，一旦备份窗口内发生过均衡或迁移，恢复后就会出现数据与元数据不一致。正确做法是使用集群级一致性备份，或在备份前停止均衡器并记录各组件的时间点。
恢复后的验证清单
恢复完成不等于任务结束。建议按以下顺序验证，确认集群真正可用：
- 启动顺序：先 config server，再各 shard，最后 mongos。
- 执行
sh.status()，确认分片列表、数据库分片状态、chunk 数量与备份前记录一致。 - 对每个分片集合执行
db.collection.getShardDistribution()，核对各 shard 上的 chunk 数与文档数是否合理。 - 抽样执行跨分片查询与写入，确认 mongos 路由正常、无“could not find host”或“chunk not found”类错误。
- 检查均衡器状态，确认恢复后是否需要重新开启，避免恢复期间自动均衡再次打乱数据分布。
分片集群的容灾能力，本质上取决于“元数据 + 所有分片数据”能否作为一个整体被一致地保护和恢复。mongos 可以随时重建，config server 和 shard 才是备份策略真正要覆盖的对象；而一致性时间点，是贯穿备份、恢复、验证全流程的核心约束。