降级MongoDB前必须先降featureCompatibilityVersion（fCV），如5.0→4.4需在Primary执行db.adminCommand({setFeatureCompatibilityVersion:"4.4",confirm:true})，且所有节点须在线、无初始同步或重分片；fCV未降则替换二进制后启动失败。
降级前必须先降 featureCompatibilityVersion
直接换二进制文件会失败，MongoDB 要求先降 featureCompatibilityVersion（fCV）到目标版本。比如从 5.0 降到 4.4，必须先在 admin 数据库执行：
db.adminCommand({ setFeatureCompatibilityVersion: "4.4", confirm: true })
这个命令只能在 Primary 上运行，且要求副本集所有节点都在线、无初始同步、无进行中的重新分片操作。如果 fCV 还是 "5.0"，哪怕你替换了 4.4 的 mongod，启动时会直接报错退出，并提示 FeatureCompatibilityVersion mismatch。
5.0 → 4.4 降级要清理不兼容数据
不是换完二进制就完事，5.0 引入的某些数据格式在 4.4 上根本不认：
- 字段名含
.或$的文档必须删掉或重命名，否则 4.4 启动时拒绝加载该集合 - 如果用了
setDefaultRWConcern设置了集群级读写关注，得手动还原成 4.4 默认值，否则部分命令可能报Unknown field - 若部署中启用了 Slim 格式时区文件（
--timeZoneInfo），必须降级到 4.4.7+，或换回传统格式文件 - 有仲裁节点（arbiter）的副本集，确认
replication.enableMajorityReadConcern配置与 4.4 兼容，必要时加--enableMajorityReadConcern false
滚动降级时 Primary 节点怎么处理
不能直接停 Primary 换二进制——这会触发非受控选举，可能导致写丢失或回滚。正确做法是：
- 先确保至少一个 Secondary 处于
SECONDARY状态且同步延迟 rs.status().members[n].optimeDate） - 在当前 Primary 上执行
rs.stepDown(30)，让它主动让位，冻结 30 秒不参选 - 等新 Primary 选出、状态稳定后，再停掉刚降级的原 Primary，换成 4.4 的
mongod启动 - 它重启后会以 Secondary 加入，等同步完成再考虑是否让它再次参选（需调
priority）
降级后最容易被忽略的验证点
很多人以为替换完二进制、fCV 改完就结束了，但实际常卡在隐性兼容问题上：
- 检查
rs.status().members[n].version是否全为 4.4.x，避免混用版本 - 运行
db.runCommand({ listCommands: 1 })，确认没有 5.0 特有命令残留（如reshardCollection） - 应用连接后执行一次带
w: "majority"的写操作，验证写关注是否生效——4.4 默认不启用 majority read concern，可能影响行为 - 特别注意：降级后无法再升回 5.0，除非重做备份恢复；fCV 降下去就不可逆，除非数据已清空
