[SERVER-71068] Partial indexes should not check FCV during startup Created: 03/Nov/22  Updated: 29/Oct/23  Resolved: 19/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 6.0.0, 6.1.0-rc4, 6.2.0-rc0
Fix Version/s: 6.0.5

Type: Bug Priority: Major - P3
Reporter: David Percy Assignee: Matt Boros
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-73105 Partial indexes should not check FCV ... Closed
Duplicate
is duplicated by SERVER-72775 Issue upgrading from 5.0.14 to 6.x Closed
Problem/Incident
is caused by SERVER-59508 Support $or, $in and multi-level expr... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: QO 2023-01-23
Participants:
Case:

 Description   

The problem:

When we check whether an index spec is valid, we inspect the parsed partialFilterExpression and check whether each operator is allowed under the current FCV. For example $or is allowed in a partial filter expression in 6.0 but not 5.x.

However, when you downgrade FCV from 6.0 to 5.x, we are not checking whether existing partial indexes are allowed under 5.x. You end up with new features in the datafiles, but an old FCV. Then during startup, we do check FCV and reject the index, so the server fails to start.

Another reason we shouldn't check FCV during startup is that determining FCV in the first place requires loading the catalog for the admin database. So if you create any partial index on the admin database (regardless of 6.0 features), then we check FCV before FCV is initialized, which fails (regardless of the value of FCV: 5.x or 6.0).


The solution:

  1. We should not check FCV during startup. When we validate a partialFilterExpression that we loaded from the datafiles, we should assume any new features are allowed. We should backport this change to 6.0.
    • For any existing datafiles, this will allow you to start the latest 6.0.x binary and either upgrade FCV or drop some indexes.
  2. We should check for 6.0-only features in partial indexes when the user attempts to downgrade FCV, and fail with CannotDowngrade if we find any.
    • For any existing datafiles, 5.x binary will still safely reject 6.0-only partial indexes during startup.

Workarounds (requested here in HELP-42790):

For future HELP tickets that run into this issue and are on a version earlier than 6.0.5, the only known workaround is to drop the partial indexes on the admin database. They can then be replaced with non-partial indexes and the FCV issue should be resolved.



 Comments   
Comment by Githook User [ 17/Jan/23 ]

Author:

{'name': 'Matt Boros', 'email': 'matt.boros@mongodb.com', 'username': 'mattBoros'}

Message: SERVER-71068 Remove partial indexes FCV startup check
Branch: v6.0
https://github.com/mongodb/mongo/commit/5e3d128c591c74669068e64452abddc5ba30d5b4

Generated at Thu Feb 08 06:17:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.