不能直接用mongodump连mongos备份分片集群，因为mongodump不感知分片拓扑，mongos并发查询各shard且无全局快照机制，导致跨分片数据不一致；必须逐个连接各shard主节点及config server，使用--archive和--oplog备份。
不能直接用 mongodump 连 mongos 备份分片集群。这么做看似简单，实际导出的数据跨分片不一致——订单在 shard1、库存在 shard2，两个分片读取时间点不同，dump 出来可能是“已下单但库存未扣减”的错位状态。
为什么 mongos 上跑 mongodump 不安全
mongodump 本身不感知分片拓扑，它只把 mongos 当成普通 mongod 转发请求。而 mongos 对每个分片的查询是并发发起、各自返回的，没有全局快照机制。即使加了 --oplog，oplog 截断点也无法对齐所有 shard 的逻辑时间。
- 现象：备份后 restore，应用报“找不到关联文档”或“状态矛盾”，查日志发现跨集合引用断裂
- 本质：
mongodump在 mongos 上执行时，等价于并发跑 N 个独立查询，不是原子快照 - 风险等级：高。线上生产环境严禁此操作
必须逐个连接 shard 主节点 + config server
安全备份的前提是：所有 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 <primary-host> --port 27018 --out /backup/shard01 --oplog --forceTableScan</primary-host> -
--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 很小，但它是恢复分片路由规则的唯一依据，删不得
真正麻烦的不是命令本身，而是时间对齐和节点状态跟踪：shard 主节点可能在备份中途切换，config server 可能因负载高响应延迟。建议用带超时和重试的 shell 脚本统一触发所有 dump，并记录每个命令的实际开始时间戳。否则你以为“同一秒启动”，实际误差超过 2 秒，一致性就崩了。
