为什么不能直接使用 mongodump 连接 mongos 来备份 MongoDB 分片集群？核心原因在于，mongodump 本身无法识别完整的分片拓扑结构，而 mongos 在并发访问各个 shard 时又缺少统一的全局快照机制，这会导致跨分片数据在备份时出现不一致。因此，正确的做法是分别连接每个 shard 的主节点以及 config server，并配合 --archive 和 --oplog 参数完成备份。
不能直接用 mongodump 连接 mongos 备份分片集群。这种方式看起来更省事，但实际上导出的数据很容易在跨分片场景下出现错位。例如订单数据位于 shard1，而库存数据位于 shard2，如果两个分片的读取时间点不同，最终备份结果就可能变成“订单已经生成，但库存还未扣减”的不一致状态。
为什么在 mongos 上执行 mongodump 不安全
mongodump 本身并不了解 MongoDB 分片集群的拓扑，它只是把 mongos 当作普通 mongod 来发送请求。而 mongos 对不同分片的查询是并发下发、分别返回的，整个过程并不存在全局一致性的快照。即使附带 --oplog 参数，也无法让所有 shard 的 oplog 截断点对齐到同一个逻辑时间。
- 常见现象：备份完成后执行 restore，应用出现“找不到关联文档”或“状态互相矛盾”等问题，排查日志后会发现跨集合引用已经断裂
- 问题本质：
mongodump在 mongos 上运行时，本质上等同于并发执行 N 个彼此独立的查询，而不是一次原子级快照备份 - 风险等级：高。在生产环境中，通常不建议也不允许这样操作
必须逐个连接 shard 主节点 + config server
要实现相对安全的 MongoDB 分片集群备份，前提是所有 dump 命令尽量在同一秒内启动，并且分别连接到每个 shard 当前的 primary 以及 config server 主节点。
- 先查看拓扑：
db.adminCommand({ listShards: 1 })，获取每个 shard 的host字段（例如shard01/10.0.1.10:27018,10.0.1.11:27018） - 再确认主节点：
rs.status()或db.isMaster()用于确认每个 shard 副本集当前 primary 的地址 - 每个 shard 执行：
mongodump --host--port 27018 --out /backup/shard01 --oplog --forceTableScan --forceTableScan必须携带：这样可以避免因为 chunk 迁移尚未结束而造成部分数据漏备份- 不要添加
--db或--collection：否则 admin 库中的用户、角色以及系统集合都可能无法被完整保留
config server 备份有硬性限制
config server 中的 config 数据库不能像普通数据库那样通过目录方式进行 dump，必须使用 --archive，并且同时带上 --oplog。
- 命令示例：
mongodump --host config-primary:27019 --archive=/backup/config.archive --oplog - 常见报错：
cannot dump config database without --archive—— 如果不加--archive，命令会直接报错并退出 - restore 时也必须使用
--archive+--oplogReplay，否则分片元数据不完整，整个集群将无法正确重建 - 虽然 config server 的 oplog 通常不大，但它是恢复分片路由规则和元数据的关键依据，绝对不能省略
真正棘手的往往不是 mongodump 命令本身，而是时间对齐和节点状态追踪。因为 shard 主节点可能会在备份过程中发生切换，config server 也可能因负载较高出现响应延迟。因此，更推荐使用带超时控制和自动重试能力的 shell 脚本，统一触发所有 dump 任务，并记录每条命令实际启动的时间戳。否则你以为所有备份操作都在“同一秒”开始，但实际偏差可能已经超过 2 秒，一旦如此，分片集群备份的一致性就会被彻底破坏。
