-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding 2018-04-23, Sharding 2019-07-01, Sharding 2019-07-15
If the DatabaseShardingState, which stores a shard's in-memory cached database version, remains a decoration on Database, then it is not possible to check a client's database version on a shard that does not actually have the database.
This is a problem because a database can be dropped and recreated on another shard, and a stale mongos can still target the old shard, which will not perform the version check and so not tell the stale mongos to refresh and reroute.
Let's make DatabaseShardingState more similar to CollectionShardingState by:
1) creating a standalone DatabaseShardingStateMap that will hold all the DatabaseShardingStates and be a decoration on ServiceContext (analogous to the CollectionShardingStateMap)
2) making _configsvrDropDatabase send _flushDatabaseCacheUpdates to all shards (analogous to _configsvrDropCollection sending setShardVersion to all shards)
- is depended on by
-
SERVER-33272 The DatabaseHolder::close() function no longer requires a global write lock and neither does the dropDatabase command.
-
- Closed
-
- is duplicated by
-
SERVER-34505 Dropping a database from a shard should clear the shard's in-memory cached database version
-
- Closed
-
- is related to
-
-
- Closed
-