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

    XMLWordPrintable

Details

    • Fully Compatible
    • ALL
    • Sharding 2018-04-23, Sharding 2019-07-01, Sharding 2019-07-15

    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)

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: