MongoDBNotes

第 27 章：升级与迁移

zjc 于 2026-01-27 发布

这是《MongoDB 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 升级改变数据库版本，迁移改变集群、云环境或数据模型。两者都属于高风险变更，必须有兼容性评估、灰度窗口、验证清单和回滚路径。

27.1 升级流程

read release notes
  -> verify compatibility
  -> backup metadata and data
  -> upgrade test environment
  -> run application tests
  -> upgrade secondaries
  -> step down primary
  -> upgrade primary
  -> verify cluster

生产升级前必须确认：

  1. 当前版本到目标版本的升级路径；
  2. Feature Compatibility Version；
  3. 驱动版本兼容；
  4. 索引和配置兼容；
  5. 备份可恢复；
  6. 回滚窗口；
  7. 变更审批。

27.2 Feature Compatibility Version

查看：

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

设置：

db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

注意：

  1. 只能按官方支持路径操作；
  2. 设置后某些旧版本回滚会受限；
  3. 必须在集群健康时执行；
  4. 命令会传播到副本集；
  5. 分片集群还需关注 Config Server 和 shard。

27.3 副本集滚动升级

推荐顺序：

  1. 备份；
  2. 先升级 Secondary；
  3. 每个节点验证复制和查询；
  4. 执行 rs.stepDown()；
  5. 升级原 Primary；
  6. 恢复后检查状态；
  7. 观察应用指标。

检查：

rs.status()
db.serverBuildInfo()
db.hello()

27.4 分片集群升级

一般顺序：

  1. 升级 Config Server 副本集；
  2. 升级 shard 副本集；
  3. 升级 mongos；
  4. 检查路由；
  5. 暂停或避开 balancer 窗口；
  6. 更新驱动配置；
  7. 验证分布式查询和事务。

分片组件版本兼容性要求更严格，必须按目标版本文档执行。

27.5 索引升级

大索引上线：

  1. 预估空间；
  2. 低峰执行；
  3. 观察复制延迟；
  4. 分批构建；
  5. 验证执行计划；
  6. 应用查询灰度；
  7. 保留删除旧索引脚本。

可先在 Hidden Secondary 或预生产环境验证，再推广生产。

27.6 数据模型迁移

新旧文档共存时：

version field
  -> dual read compatible
  -> write new format
  -> backfill old documents
  -> verify
  -> remove old logic

示例：

{
  schema_version: 2,
  shipping_address: {
    country: "CN",
    city: "Shanghai"
  }
}

应用读取时兼容缺省字段，写入时写新版本，后台任务分批回填。

27.7 集群间迁移

流程：

inventory
  -> create target
  -> full copy
  -> enable change stream or replication
  -> catch up
  -> verify counts and samples
  -> read only switch
  -> write switch
  -> observe
  -> retire source

验证：

  1. 集合数量；
  2. 文档数量；
  3. 索引定义；
  4. 用户角色；
  5. validator；
  6. 分片键；
  7. 业务抽样；
  8. 应用读写；
  9. 监控曲线。

27.8 云迁移

关注：

  1. VPC 和 DNS；
  2. 连接串切换；
  3. TLS 和密钥；
  4. 带宽和耗时；
  5. 云盘性能等级；
  6. 备份权限；
  7. 监控接入；
  8. 成本模型；
  9. 安全审计；
  10. 回滚窗口。

跨云迁移建议先双读验证，再短暂停写切换，最后处理增量。

27.9 回滚策略

回滚前提：

  1. 旧版本或旧集群仍可运行；
  2. 数据没有不可逆 schema 变更；
  3. 增量可以回流；
  4. 连接配置可快速切换；
  5. 应用兼容新旧格式；
  6. 回滚时间在窗口内。

超过回滚窗口后，应前向修复，不能强行回退造成数据丢失。

27.10 常见问题

问题 处理
驱动不兼容 先升级驱动和测试
复制延迟升高 暂停升级或批处理
回滚受限 检查 FCV 和持久特性
索引构建慢 控制批次和资源
迁移后路由错 校验分片元数据
数据抽样不一致 全量对账并暂停切换

本章小结

升级和迁移的成功关键不是执行命令，而是兼容性验证、备份、灰度、监控验证和回滚设计。副本集滚动升级要保护多数派，分片升级要保护元数据，数据模型迁移要长期兼容新旧格式。

思考题

  1. 为什么升级前必须检查驱动版本？
  2. FCV 设置为什么影响回滚？
  3. 分片升级为什么要先处理 Config Server？
  4. 数据模型迁移如何避免停机？
  5. 什么时候应该选择前向修复而不是回滚？