[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: |
|
||||||||||||||||||||||||||||||||||||
| 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 Mongod 3.6 must always have the featureCompatibilityVersion document, as described in |
| Comments |
| Comment by Githook User [ 08/Dec/17 ] |
|
Author: {'name': 'Xiangyu Yao', 'username': 'xy24', 'email': 'xiangyu.yao@mongodb.com'}Message: (cherry picked from commit 9ab80a38613917a9d4c66331c923e09f3151445a) |
| Comment by Githook User [ 22/Nov/17 ] |
|
Author: {'name': 'Xiangyu Yao', 'username': 'xy24', 'email': 'xiangyu.yao@mongodb.com'}Message: |
| 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. |
| 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 |
| 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? |