[SERVER-53643] Startup can see old version of featureCompatibilityVersion document Created: 07/Jan/21 Updated: 29/Oct/23 Resolved: 27/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.15, 4.4.7, 4.0.26, 5.0.0-rc3, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gregory Noma | Assignee: | Matthew Russotto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | post-rc0 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v5.0, v4.4, v4.2, v4.0
|
||||||||
| Sprint: | Repl 2021-04-05, Repl 2021-04-19, Repl 2021-05-31 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 24 | ||||||||
| Description |
|
During startup, the featureCompatibilityVersion document is checked to ensure a valid FCV. However, it may be the case that the document was recently updated and this updated version needs to be recovered from the oplog through by replication recovery (as opposed to being able to recover it through WT journal recovery). If this occurs, this FCV validity check could fail even if the FCV had been set to a valid value. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 30/Jun/21 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit f34d72aed2861b91fdd2907058d1fbec7f66e328) |
| Comment by Githook User [ 30/Jun/21 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: |
| Comment by Githook User [ 30/Jun/21 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit f34d72aed2861b91fdd2907058d1fbec7f66e328) |
| Comment by Githook User [ 16/Jun/21 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: (cherry picked from commit 11b41d28993c539b2b383d44f7969e6dd8e3f968) |
| Comment by Githook User [ 27/May/21 ] |
|
Author: {'name': 'Matthew Russotto', 'email': 'matthew.russotto@mongodb.com', 'username': 'mtrussotto'}Message: |
| Comment by Matthew Russotto [ 26/May/21 ] |
|
To be effective this has to be implemented in the version being upgraded from. |
| Comment by Matthew Russotto [ 19/May/21 ] |
|
Attached "breakupgrade.js" which reproduces the failure in 5.0. |
| Comment by Matthew Russotto [ 19/May/21 ] |
|
I believe it would not be safe to skip this check; the oplog entries we are applying were applied using a 4.0 binary under a 3.6 FCV, and it is not necessarily safe to apply those same oplog entries using a 4.0 FCV and 4.2 binary. We may need a change to the upgrade procedure, or perhaps special case getParameter for FCV to wait for the FCV to become stable. |