mongodump + mongorestore 不适合灰度迁移，因其为全量快照操作，无法按业务条件（如时间、标签、元数据）筛选迁移，不支持增量同步、无迁移状态标记、不能原子控制读写路由，易导致数据断层与路由错乱。
GridFS 灰度迁移不能靠 mongodump/mongorestore 直接做，因为它们不区分文件版本、不支持按时间/标签/元数据切片，且无法原子性控制新旧读写路由。
为什么 mongodump + mongorestore 不适合灰度场景
这两个工具是全量快照式操作：mongodump 会拉取整个 fs.files 和 fs.chunks 集合，mongorestore 则直接覆盖目标库。问题在于：
- 无法只迁移“最近7天上传的文件”或“
status: "draft"的文件”这类业务语义条件 - 迁移过程中新文件仍在原库写入，但恢复后目标库没有这些增量，导致数据断层
- 没有机制标记哪些文件已迁移、哪些还在双写中，无法安全切换读流量
- 如果用自定义桶名（如
myBucket），mongodump默认只处理fs.*，必须显式指定--collection，极易漏掉
真正可行的灰度路径：双写 + 元数据标记 + 渐进读切换
核心不是“搬数据”，而是“控制流向”。你需要在应用层介入，而不是依赖命令行工具：
- 在应用写入逻辑中，同时向旧 GridFS 桶（如
fs）和新桶（如fs_v2）写入同一份文件，并在files文档中写入标记字段，例如{"migrated": false, "version": "v2"} - 启动一个后台任务（如 cron job 或 worker），定期扫描旧桶中
migrated: false的文件，调用bucket.openDownloadStream()读取再写入新桶，并更新旧文档的migrated: true - 读请求先查新桶；若未命中，再查旧桶，并记录
fallback_count指标；当该指标连续 1 小时为 0，说明存量文件已基本覆盖，可关闭回退逻辑 - 关键点：所有写操作必须带
_id复制（GridFS 文件 ID 是 UUID 或 ObjectId，需保持一致），否则读路由无法对齐
用 mongofiles 做小范围验证，但别用于生产灰度
mongofiles 是唯一能按单个文件名操作 GridFS 的官方 CLI 工具，适合抽样验证迁移逻辑是否正确：
- 从旧库下载一个测试文件：
mongofiles -u admin -p pwd --authenticationDatabase admin -d demo1 -r fs get "report_20260720.pdf" - 上传到新库同名桶：
mongofiles -u admin -p pwd --authenticationDatabase admin -d target -r fs_v2 put "report_20260720.pdf" - 注意：
-r参数必须与实际桶名一致，fs_v2和fs是完全隔离的两套files/chunks集合 - 它不支持过滤、不支持并发、不支持进度追踪，仅限人工验证，千万别用它跑全量
最容易被忽略的坑：索引缺失导致查询变慢十倍
GridFS 桶默认会在 files.filename、files.uploadDate、chunks.files_id 上建索引，但新桶不会自动继承——哪怕你用 mongorestore 恢复了集合，索引也不会被重建。
必须手动补上，否则按文件名查、按时间范围查都会全表扫：
db.fs_v2.files.createIndex({ "filename": 1, "uploadDate": -1 })
db.fs_v2.chunks.createIndex({ "files_id": 1, "n": 1 })
这个动作在灰度前就要完成，而且要在新桶首次写入前执行，否则写入期间建索引会锁表（尤其 chunks 表大时）。
