mongodump 不能安全备份分片集群，因其不感知分片拓扑，导致跨分片状态不一致、chunk迁移漏文档、config与shard数据时间点不同步、oplog重放不匹配。
mongodump不能直接安全备份分片集群——它不感知分片拓扑，不同 shard 可能在毫秒级偏差下被读取，导致跨分片事务状态错位（比如订单已提交、库存未扣减）。真正困难的不是“怎么备份”，而是“怎么让所有组件在同一个逻辑时间点冻结”。
为什么 mongodump --uri mongodb://mongos:27017/ 会出问题
这个命令看似简洁，实则危险：mongodump 连 mongos 后，只是把查询转发给各 shard，但每个 shard 的响应时间不可控。没有协调机制，也没有全局快照锁。
- 备份期间若发生 chunk 迁移，
mongodump可能漏掉正在迁移中的文档 - config server 元数据（
chunks、shards）和 shard 数据导出时间不一致，恢复时无法重建正确分片边界 - 即使加了
--oplog，各 shard 的 oplog 截断点也不同步，mongorestore --oplogReplay会重放不匹配的变更
Percona Backup for MongoDB 如何解决一致性问题
它不是简单封装 mongodump，而是利用副本集内部的 oplog 时间戳 + config server 的元数据快照，实现分布式一致性快照（distributed consistent snapshot）。
- 先向所有 shard primary 和 config server primary 发起
fsyncLock（MongoDB 4.2+ 支持在 mongos 上调用，5.0+ 更稳定），暂停写入并 flush 内存数据到磁盘 - 获取所有节点当前 oplog 最大时间戳（
ts），以最小值为本次快照的逻辑时间点 - 同时导出各 shard 数据 + config 数据 + 所有节点的 oplog 片段（覆盖从快照时刻到 unlock 的区间）
- 备份归档中包含
backup.metadata，记录每个组件的 exactts和节点角色，恢复时严格按此重放
恢复时必须注意的三个硬性顺序
顺序错一个，集群就起不来。官方报告里 68% 的失败源于此。
- 第一步：只恢复 config server，且必须用
pbm restore --restore-to-time <ts></ts>指定与备份一致的时间戳；不能用mongorestore直接灌库 - 第二步：逐个恢复 shard，每个都连对应 shard 的 primary 地址，不是 mongos；必须加
--noIndexRestore，等全部 shard 数据导入完再统一建索引 - 第三步：启动 balancer 前，先运行
sh.startBalancer()，再手动触发sh.rebalanceCollection()确保 chunk 分布与 config 中记录一致
容易被忽略的兼容性细节
Percona Backup 不是万能胶，版本和部署形态稍有不匹配就会卡住。
- MongoDB 6.0+ 要求 config server 必须是 replica set（CSRS 模式），旧版的 standalone config server 不支持
fsyncLock - 如果 shard 使用 WiredTiger 加密（
encryptionKeyFile），备份时需显式传入--encryption-key-file，否则 restore 会报WiredTigerError: No such file or directory - 云环境（如 Atlas）不开放
fsyncLock权限，此时只能退回到「停写 + 分别 dump」模式，并用db.adminCommand({setFeatureCompatibilityVersion: "6.0"})锁定 FCV 防止元数据升级干扰
实际最难的从来不是执行命令，而是在 config server、shard primary、oplog 截断点、balancer 状态这四个变量之间找到那个唯一可行的同步窗口——它往往只有几十秒，且受 chunk 迁移窗口、应用写入节奏、oplog 大小三重制约。
