fcv不能独立升降，因其是mongodb对当前部署是否安全启用某版本新特性的声明标记，与二进制版本强绑定：fcv设为6.0但运行5.0二进制会启动报错，反之新功能不可用或启动失败，下调前未清理不兼容数据会导致查询异常。
不能直接修改FCV（Feature Compatibility Version）来“降级”功能，必须先升级二进制版本，再下调FCV；反之，升级FCV前必须确保所有节点已运行目标MongoDB二进制版本，否则会触发启动失败或数据损坏。
为什么FCV不能独立升降？
FCV不是配置开关，而是MongoDB对“当前部署是否已安全启用某版本新特性”的声明标记。它和二进制版本强绑定：
- FCV设为
6.0但节点仍运行5.0二进制 → 启动时直接报错：IllegalOperation: Cannot set featureCompatibilityVersion to 6.0 when running version 5.0 - FCV保持
5.0却强行运行6.0二进制 → 新功能（如$merge增强、索引构建并发控制）不可用，且可能因元数据格式不兼容导致mongod拒绝启动 - FCV下调（如从
6.0→5.0）前未清理不兼容数据（如6.0引入的timeseriesbucket优化字段）→ 升级回5.0后可能出现InvalidNamespace或查询返回空结果
安全修改FCV的三步顺序
无论升还是降，都必须严格按以下顺序执行，跳步即风险：
-
先统一二进制版本：所有副本集成员（包括arbiter）必须运行同一目标MongoDB版本（如全部升到
6.0.20），通过db.version()逐个确认 -
再修改FCV：在PRIMARY节点执行
db.adminCommand({setFeatureCompatibilityVersion: "6.0"})，命令需认证到admin库，且仅影响当前副本集（不跨分片） -
最后验证状态：执行
db.adminCommand({getCmdLineOpts: 1})检查featureCompatibilityVersion字段值，并用rs.status()确认所有成员stateStr为PRIMARY/SECONDARY，无STARTUP2卡住
常见错误场景与应对
实际操作中最容易栽在这些地方：
- 误在SECONDARY节点执行FCV命令 → 报错
NotMaster，必须切到PRIMARY（可用rs.isMaster().ismaster确认） - FCV下调前未停写+清空6.0特有集合 → 比如已创建
timeSeries集合并写入，降FCV到5.0后该集合无法读取，需先导出再重建 - 使用
mongosh连接串未指定?authSource=admin→ 认证失败，命令被拒绝，错误信息是Unauthorized: not authorized on admin to execute command { setFeatureCompatibilityVersion: ... } - 批量脚本中用变量传FCV值（如
db.adminCommand({setFeatureCompatibilityVersion: fcvVar})）→ 若fcvVar未定义，实际发的是null，触发FailedToParse: setFeatureCompatibilityVersion must be a string
FCV修改后必须做的验证动作
改完不是就结束了，这几个检查点漏掉一个都可能埋雷：
- 立刻在每个节点运行
db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})，确认返回值一致且无error字段 - 尝试创建一个新集合并插入文档：
db.test.insertOne({x: 1})，再从SECONDARY连入执行db.getMongo().setReadPref('secondary')后查一遍，验证读写通路正常 - 如果之前用过6.0的
$jsonSchema新语法，降FCV后要重写校验逻辑，因为minLength/maxLength在5.0中不支持嵌套数组校验 - 监控日志是否有
WARNING: Feature compatibility version is lower than server version——这说明FCV没跟上二进制，虽能运行但功能受限
