Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-34431

Move DatabaseShardingState into its own map to correctly handle database versioning in face of drop/recreate

    • 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)

            Assignee:
            janna.golden@mongodb.com Janna Golden
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: