[SERVER-29453] Disallow removing the featureCompatibilityVersion document Created: 06/Jun/17  Updated: 30/Oct/23  Resolved: 22/Nov/17

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Xiangyu Yao (Inactive)
Resolution: Fixed Votes: 0
Labels: 3.7BackgroundTask
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-29452 Handle missing featureCompatibilityVe... Closed
Related
related to SERVER-32097 Updating the FCV document directly be... Closed
related to SERVER-35136 Remove featureCompatibilityVersion do... Closed
related to SERVER-64491 Reconsider allowing the system.js col... Closed
is related to SERVER-29350 Bump featureCompatibilityVersion to 3.6 Closed
is related to SERVER-29448 Disallow dropping "admin" and "local"... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Storage 2017-11-13, Storage 2017-12-04
Participants:
Linked BF Score: 0

 Description   

Removing the featureCompatibilityVersion document, dropping the admin.system.version collection, or dropping the admin database should fail. This can either fail by fasserting or by aborting the transaction and returning an error. If we fail by fasserting, we should be able to recover using the startup parameter in SERVER-29452.

Mongod 3.6 must always have the featureCompatibilityVersion document, as described in SERVER-29452.



 Comments   
Comment by Githook User [ 08/Dec/17 ]

Author:

{'name': 'Xiangyu Yao', 'username': 'xy24', 'email': 'xiangyu.yao@mongodb.com'}

Message: SERVER-29453 Disallow removing featureCompatibilityVersion document and renaming collection

(cherry picked from commit 9ab80a38613917a9d4c66331c923e09f3151445a)
Branch: v3.6
https://github.com/mongodb/mongo/commit/18b19448c41bed978b936b2612c777105ad9af6d

Comment by Githook User [ 22/Nov/17 ]

Author:

{'name': 'Xiangyu Yao', 'username': 'xy24', 'email': 'xiangyu.yao@mongodb.com'}

Message: SERVER-29453 Disallow removing featureCompatibilityVersion document and renaming collection
Branch: master
https://github.com/mongodb/mongo/commit/9ab80a38613917a9d4c66331c923e09f3151445a

Comment by Eric Milkie [ 19/Oct/17 ]

The admin database is no longer droppable, but one can still remove the fCV document, or rename its collection. The behavior on removal is that mongod resets fCV to "3.4"; this is problematic, of course, because the on-disk value is interpreted as "3.2" upon mongod restart.
The work for this ticket will be to prohibit removal of admin.system.version, and to prohibit renaming its collection, after coordinating with backup and mongorestore procedures.

Comment by Andy Schwerin [ 19/Oct/17 ]

Better talk to backup/mongorestore devs before implementing.

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

spencer also pointed out that we must prevent renaming of the admin.system.version collection.

Comment by David Storch [ 10/Jul/17 ]

Got it, thanks Eric.

Comment by Eric Milkie [ 10/Jul/17 ]

I expect that will fall out of SERVER-29452 once we decide what work to do for that ticket. Agree that running a 3.6 binary without having first setFCV to 3.4 is problematic and must be handled in some fashion.

Comment by David Storch [ 07/Jul/17 ]

milkie geert.bosch, what was the reasoning behind changing the fixVersion to "3.5 Desired"? Do we have another plan for how to ensure that a user has run setFCV("3.4") before starting the upgrade to 3.6?

Comment by Andy Schwerin [ 06/Jun/17 ]

Yeah, definitely fail by uasserting. Doing this via the OpObserver should be plausible.

Comment by Tess Avitabile (Inactive) [ 06/Jun/17 ]

That seems reasonable here.

Comment by Eric Milkie [ 06/Jun/17 ]

I agree it should be prevented, but I see no reason to crash the server. Certainly the server doesn't crash if a user attempts other operations they shouldn't do, like dropping the oplog while in replica set mode. It just uasserts and returns an error for the operation.

Comment by Tess Avitabile (Inactive) [ 06/Jun/17 ]

The user really should not be dropping this database/collection or removing this document. If they are doing so, it seems okay to end up in a "bad state". As long as there is a way to recover, such as by starting up with a server parameter to set the featureCompatibilityVersion.

Comment by Eric Milkie [ 06/Jun/17 ]

I really don't think we can make it fassert – aren't these all operations that a user could attempt?

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