Sample Header Ad - 728x90

mongodb downgrade stuck in downgrading from setFeatureCompatibilityVersion: “6.0” to “5.0”

0 votes
0 answers
103 views
So I've encountered essentially the same (unanswered) problem posted about [here](https://www.mongodb.com/community/forums/t/stuck-in-downgrading-from-setfeaturecompatibilityversion-6-0-to-5-0/295938) . I upgraded an existing sharded cluster from 5.0.30 to 6.0.19. And, thinking everything was working, I got overconfident and updated the FCV, only to discover that our existing clients were using libraries that broke on 6.0. So now I'm trying to do the dangerous thing and move it back to 5.0. In our test cluster, this worked fine. But in production (because of course it's production), the attempt to setFeatureCompatibilityVersion seems to have deadlocked (waiting over an hour), and we have the following observed behavior: 1. All the non-config, non-arbiter mongod instances, when queried with db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }), report featureCompatibilityVersion: { version: '5.0' } 2. The arbiters all report featureCompatibilityVersion: { version: '6.0' } 3. The config replicas all report featureCompatibilityVersion: { version: '5.0', targetVersion: '5.0', previousVersion: '6.0' } Unlike the linked question, there was no obvious error from the attempt to set the FCV (no tables reported as incompatible, it just deadlocks). Is there any reasonable way to diagnose and correct this problem and get us back to a working 5.0 FCV (and then downgrade the binaries, at least for mongos since they're the entry point that's likely responsible for the incompatibility with our code, since the code doesn't talk to the mongods directly)?
Asked by ShadowRanger (101 rep)
Jan 16, 2025, 03:19 AM