rs.status()报错“not master and slaveOk=false”或连不上，根本原因是副本集成员版本不一致导致协议解析失败；必须统一所有节点主版本号，验证mongod/mongos版本及fCV，严禁跳版本升级。
rs.status() 报错 "not master and slaveOk=false" 或直接连不上
这是副本集成员版本不一致最典型的表象：节点看似在运行，但 rs.status() 返回空、超时，或提示连接被拒绝。根本原因不是网络不通，而是新旧版本间协议解析失败——比如 7.0 的 mongod 向 6.0 的 mongos 发送了带 7.0 元数据格式的响应，对方直接丢弃，不报错也不重试。
必须立刻查清每个节点的真实版本：mongod --version、mongos --version，再进每个实例执行：db.adminCommand({getFeatureCompatibilityVersion: 1})。注意返回字段是 version，不是 featureCompatibilityVersion；如果命令报 no replset config，说明该节点还没完成初始化，先别急着设 fCV。
featureCompatibilityVersion 设成 "7.0" 但启动仍失败
fCV 不是“设了就生效”的开关，它依赖底层数据文件格式和日志结构。如果你从 6.0 升级到 7.0 后手动设了 setFeatureCompatibilityVersion: "7.0"，但某个节点实际还是 6.0 二进制在跑，就会触发 Wrong mongod version 错误——日志里明确写 “expected fcv 7.0, got 6.0” 或类似内容。
此时不能降级 fCV（MongoDB 不允许），只能：
- 停掉所有节点，确认每个
mongod进程都用的是 7.0+ 二进制 - 检查
/etc/mongod.conf中的binPath是否指向正确版本（尤其在多版本共存环境） - 删掉旧版残留的 systemd service 文件，避免
systemctl start mongod启动错二进制 - 用
mongod --config /etc/mongod.conf --version验证配置加载的确实是目标版本
副本集初始化后部分节点始终是 STARTUP2 状态
常见于混合部署场景：一个节点是 7.0，另两个是 6.0.15。即使 rs.initiate() 成功，6.0 节点会拒绝同步 7.0 节点发来的 oplog 条目，因为它不认识新的操作类型或字段名，日志里只有一行 Skipping op with unknown operation type，然后卡住。
解决路径很硬：
- 所有副本集成员必须使用同一主版本号（如全部为 7.0.x），次版本号可不同，但主版本必须一致
- 升级顺序不可逆：先升级所有 secondary，再 stepDown primary，最后升级原 primary
- 升级完一个节点后，必须等它进入
SECONDARY状态且optimeDate追平，再升下一个 - 不要跳过中间版本——从 5.0 直升 7.0 会导致 fCV 无法设置，因为缺少 6.0 的迁移桥接逻辑
mongod 启动日志出现 "Incompatible featureCompatibilityVersion" 但没说哪个节点
这个错误通常出现在 config server 或 shard 节点上，但它不指明冲突来源。真正的问题是：当前节点的 fCV 值高于它能通信的其他组件版本所支持的上限。
例如你设了 fCV = "7.0"，但集群里还有个 6.0 的 mongos 在转发请求，它读不懂 7.0 的 chunk 元数据格式，config server 就会在日志里记下这条警告，然后静默拒绝写入——后续 sh.status() 看不到新分片，moveChunk 一直 pending。
关键动作只有两个：
- 查全集群所有组件版本：
db.version()（在每个 mongos 和 mongod 上）、mongos --version、mongod --version - fCV 必须等于集群中最低版本组件所支持的最高 fCV 值（查官方《Version Compatibility Matrix》），比如最低是 6.0 节点，fCV 就不能设为 "7.0"
版本混用不是“能连上就行”，而是协议层已断裂。修复永远从版本对齐开始，别在 fCV 上绕弯子。
