[SERVER-30993] Setting featureCompatibilityVersion to 3.4 should remove UUIDs even if existing featureCompatibilityVersion is 3.4 Created: 07/Sep/17  Updated: 30/Oct/23  Resolved: 21/Sep/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.5.13

Type: Bug Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage 2017-10-02
Participants:

 Description   

When setting featureCompatibilityVersion to 3.4, we only remove UUIDs if the existing featureCompatibilityVersion was 3.6. However, if we crash between setting the featureCompatibilityVersion to 3.4 and completing removing UUIDs, then if we run the setFeatureCompatibilityVersion command again, we will not attempt to finish removing UUIDs.



 Comments   
Comment by Githook User [ 21/Sep/17 ]

Author:

{'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}

Message: SERVER-30993 Always remove UUIDs when setting featureCompatibilityVersion to 3.4
Branch: master
https://github.com/mongodb/mongo/commit/532ab3543012436e8274740301f29457ee4e9fdb

Comment by Spencer Brody (Inactive) [ 08/Sep/17 ]

Yep, that's correct. We never formalized the notion of schemaVersion but conceptually it still applies. Schema version 3.6 basically means that UUIDs are present. Upgrading from 3.4->3.6 first goes from SV3.4, FCV3.4 -> SV3.6 , fcv3.4 by adding UUIDS, then there's a second step to go from SV3.6, FCV3.4 -> SV3.6, FCV3.6. Downgrading does the same steps in reverse. The setFeatureCompatibilityVersion command does both of these steps in one execution, but if you crash in the middle you could be left partway through, so you need to keep running the command until you get an 'ok' status for it to be successful.

Comment by Tess Avitabile (Inactive) [ 07/Sep/17 ]

When changing featureCompatibilityVersion from 3.4 to 3.6, we generate UUIDs before changing the featureCompatibilityVersion. When changing featureCompatibilityVersion from 3.6 to 3.4, we generate UUIDs after changing featureCompatibilityVersion. IIRC, this is so that when the featureCompatibilityVersion is 3.6, we can be certain that all collections have UUIDs and use this information for rollback.

CC spencer

Comment by Eric Milkie [ 07/Sep/17 ]

Why would we write the fcv document durably before we had finished doing the tasks necessary to downgrade to fcv 3.4? I thought we would write the document last, in order to avoid this scenario.

Generated at Thu Feb 08 04:25:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.