2. 迁移升级前的资产盘点

迁移升级最怕的不是操作复杂，而是“不知道自己有什么”。很多团队在切换窗口才发现某个业务库没有纳入备份、某个分片键设计导致无法直接搬迁、某个应用账号权限依赖了旧版本的角色继承关系。资产盘点的目标，就是把 MongoDB 部署中所有会影响迁移决策的对象和关系，变成一份可核对、可评估、可执行的清单。

盘点不是简单执行几条命令，而是围绕“迁移单元”建立完整视图。一个迁移单元通常包括：数据库、集合、索引、用户与角色、副本集或分片集群拓扑、以及它们之间的依赖关系。下面按对象逐层展开，并给出可直接参考的盘点命令与记录字段。

一、数据库与集合：确定迁移粒度

首先列出所有数据库及其大小。在 mongosh 中执行：

db.adminCommand({ listDatabases: 1, nameOnly: false })

输出中要重点关注 name、sizeOnDisk、empty。对于非空库，继续进入每个库统计集合：

use appdb
db.getCollectionNames()
db.stats()

集合层面需要记录：集合名、文档数、平均文档大小、是否有上限集合（capped）、是否为时间序列集合（time series）、是否使用了通配符索引或加密字段。特别要注意 system.profile、system.views 等系统集合，它们通常不需要迁移，但视图定义需要单独导出。

对于大集合，还要评估是否包含分片键、是否有 TTL 索引、是否存在大量删除后留下的空洞。这些信息决定迁移时采用全量复制、增量同步还是按时间窗口分批搬迁。

二、索引：迁移后性能的关键

索引是迁移中最容易被忽略、却最影响上线后性能的资产。对每个集合执行：

db.getCollection("orders").getIndexes()

记录每个索引的 name、key、unique、sparse、partialFilterExpression、expireAfterSeconds 以及是否包含排序规则（collation）。迁移后如果只搬数据不建索引，查询会迅速退化为全表扫描；如果索引顺序或选项不一致，唯一性约束和 TTL 行为也会改变。

建议在清单中为每个索引标注“迁移后必须重建”或“可延迟重建”。对于唯一索引，还要确认目标版本是否支持相同的部分索引表达式。

三、用户与角色：权限不能靠猜

用户和角色决定了应用能否在目标环境正常连接。执行：

use admin
db.system.users.find({}, { user: 1, db: 1, roles: 1, mechanisms: 1 })
db.system.roles.find({}, { role: 1, db: 1, privileges: 1, roles: 1 })

需要记录：用户名、认证库、认证机制（SCRAM-SHA-1/SCRAM-SHA-256）、直接角色、继承角色、以及自定义角色中的 privileges。特别注意跨库角色和内置角色（如 readWriteAnyDatabase、clusterMonitor）的依赖。如果目标版本调整了角色权限模型，必须在清单中标记“需重新验证”。

四、副本集与分片集群拓扑：决定迁移路径

拓扑信息直接决定迁移方式。对副本集执行：

rs.status()
rs.conf()

记录成员主机、端口、优先级、隐藏节点、延迟节点、仲裁节点、投票配置以及当前主节点。对分片集群执行：

sh.status()
db.adminCommand({ listShards: 1 })
db.adminCommand({ getShardMap: 1 })

重点记录：分片数量、每个分片的副本集名称、分片键、块分布、均衡器状态、config server 的副本集配置。分片集群迁移时，分片键是否可变更、是否包含哈希前缀、是否存在孤立文档，都会影响搬迁方案。

五、形成迁移升级清单

把上述信息汇总成一张可执行的清单。清单不是简单罗列，而是为每个对象标注迁移策略和风险等级。建议字段如下：

清单完成后，还需要做一次交叉核对：每个业务库是否都有对应的用户和角色？每个分片集合的分片键是否在目标版本中仍然有效？每个唯一索引是否会在数据合并时产生冲突？这些问题的答案，决定了迁移窗口内是否需要额外的数据清洗或索引调整。

完成资产盘点后，你会得到一份包含数据库、集合、索引、用户、角色和拓扑的完整清单。这份清单是后续制定迁移方案、评估停机窗口、设计回滚策略的直接输入。没有它，迁移就只能靠运气；有了它，每一步操作都有据可依。