[SERVER-30793] merge setFeatureCompatibilityVersion and _configsvrSetFeatureCompatibilityVersion Created: 23/Aug/17  Updated: 30/Oct/23  Resolved: 09/Oct/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: Maria van Keulen Assignee: Esha Maharishi (Inactive)
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-31231 prevent addShard and shardCollection ... Closed
Duplicate
is duplicated by SERVER-31214 config server should call setFeatureC... Closed
Related
related to SERVER-31017 Race condition in setFeatureCompatibi... Closed
related to SERVER-32284 awaitReplication can hang when the op... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-10-02, Sharding 2017-10-23
Participants:
Linked BF Score: 0

 Description   

Currently, the schema upgrade work is done in SetFeatureCompatibilityVersionCmd::run(), which is not run when config servers run _configsvrSetFeatureCompatibilityVersion upgrade, and so collections in config do not get assigned UUIDs.

This ticket should make setFeatureCompatibilityVersion take a ResourceMutex so that only one instance of it can run at a time.

It should also prevent a user from initiating downgrade while a previous upgrade has not completed and vice versa.



 Comments   
Comment by Githook User [ 09/Oct/17 ]

Author:

{'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}

Message: SERVER-30793 merge setFeatureCompatibilityVersion and _configsvrSetFeatureCompatibilityVersion
Branch: master
https://github.com/mongodb/mongo/commit/6787c13d49e82c33c69178162261de03d8430ea8

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

Yes, these are duplicates now.

Comment by Andy Schwerin [ 22/Sep/17 ]

Yes. Done.

Comment by Esha Maharishi (Inactive) [ 22/Sep/17 ]

Should SERVER-31214 be closed as a dupe of this ticket?

Comment by Andy Schwerin [ 22/Sep/17 ]

Yes, I believe that is correct tess.avitabile.

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

schwerin, I think we agreed that direct write to admin.system.version should not add/strip UUIDs, is that correct? So the only work for this ticket is to ensure that UUIDs for collections on the config servers are correctly added/stripped when _configSvrSetFeatureCompatibilityVersion is called?

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

Repro:

> db.adminCommand({setFeatureCompatibilityVersion: "3.4"})
{ "ok" : 1 }
> db.system.version.update({_id: "featureCompatibilityVersion"}, {$set: {version: "3.6"}})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})
{ "featureCompatibilityVersion" : "3.6", "ok" : 1 }
> db.getCollectionInfos()
[
	{
		"name" : "system.version",
		"type" : "collection",
		"options" : {
			
		},
		"info" : {
			"readOnly" : false
		},
		"idIndex" : {
			"v" : 1,
			"key" : {
				"_id" : 1
			},
			"name" : "_id_",
			"ns" : "admin.system.version"
		}
	}
]

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

I disagree. As described in the ticket, the upgrade/downgrade work for collection UUIDs should be moved to FeatureCompatibilityVersion::set(). Not only will this ensure that collections on the config servers get UUIDs, it will also ensure that UUIDs get added/removed when the featureCompatibilityVersion is changed by directly writing to admin.system.version.

Comment by Esha Maharishi (Inactive) [ 23/Aug/17 ]

Note, this call https://github.com/mongodb/mongo/blob/r3.5.12/src/mongo/db/s/config/configsvr_set_feature_compatibility_version_command.cpp#L116-L117 is not enough to make the config server generate UUIDs for its collections (or perform any upgrade steps that are part of the setFeatureCompatibilityVersion command).

Instead, the SetFeatureCompatibilityCommand::run() must actually be called, either through DBDirectClient or runCommandDirectly()

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