[SERVER-35136] Remove featureCompatibilityVersion document restoration based on UUIDs during --repair Created: 21/May/18  Updated: 09/Jul/18  Resolved: 09/Jul/18

Status: Closed
Project: Core Server
Component/s: Storage, Upgrade/Downgrade
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Maria van Keulen Assignee: Louis Williams
Resolution: Won't Fix Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-29452 Handle missing featureCompatibilityVe... Closed
is related to SERVER-29453 Disallow removing the featureCompatib... Closed
Sprint: Storage NYC 2018-07-16
Participants:

 Description   

As of SERVER-29452, the featureCompatibilityVersion document can be restored after being accidentally deleted via --repair. As of SERVER-29453, it is prohibited to remove the FCV document. One danger with having this behavior is it potentially allows users to force an FCV upgrade by removing the FCV document (or using a workaround to avoid the handling in SERVER-29453) and then running --repair with a newer binary version. MongoDB 4.0 handled this risk by refusing to repair the FCV document unless all collections had UUIDs. This handling will not address the risk of someone removing the document in MongoDB 3.6 and then running --repair with MongoDB 4.2. The usefulness of this --repair behavior should be re-evaluated with respect to the risks and costs of keeping it around.



 Comments   
Comment by Louis Williams [ 09/Jul/18 ]

Closing because we do not want to prevent repair from completing for any reason, and because this is a very unlikely behavior in 4.2 that we are choosing not to support.

Comment by Louis Williams [ 06/Jul/18 ]

The work here should be to unconditionally restore the FCV document to the value of the previous version. This is similar to the current behavior, but we will remove the code that uses UUID information to decide which version of the document to restore. For the future, we will no longer use any feature-specific side effects to deduce a data directory's FCV version.

Unless the admin.system.version collection were corrupted, the only way the document could be missing is if the user were running on a 3.2 data directory, and we will explicitly not support that.

In the unlikely event that the document is corrupted, we do not believe a user will have any reason to use a different binary version to run repair than the one they already have. If they do, undefined behavior should expected.

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