[SERVER-34431] Move DatabaseShardingState into its own map to correctly handle database versioning in face of drop/recreate Created: 12/Apr/18 Updated: 29/Oct/23 Resolved: 08/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pm-1051-legacy-tickets | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Sprint: | Sharding 2018-04-23, Sharding 2019-07-01, Sharding 2019-07-15 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
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) |
| Comments |
| Comment by Githook User [ 08/Jul/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |