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

Make _configsvrCreateDatabase send _flushDatabaseCacheUpdates to primary shard even if database already existed in config.databases

    • Fully Compatible
    • v4.4
    • Sharding 2020-03-23
    • 28

      Currently, if a config stepdown occurs after the database has been written to the sharding catalog but before the config sends _flushDatabaseCacheUpdates to the primary shard, a _configsvrCreateDatabase retry will see that the database already exists in the sharding catalog, and so returns early without running _flushDatabaseCacheUpdates.

      As a result, a database can be created even though the primary shard's filtering metadata for the database is "unknown." This is not incorrect, but is not optimal as described here

      Making _configsvrCreateDatabase send _flushDatabaseCacheUpdates even if the database already exists is not a perfect solution, since if the router does not retry (e.g., because the router crashed) or exhausts its retries (e.g., due to repeated network errors), this issue can still occur. However, this solution will at least prevent the BF from happening on Evergreen. A correct solution would require a larger design change to how the sharding catalog is kept in sync between the config server and shards.

            blake.oler@mongodb.com Blake Oler
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            0 Vote for this issue
            2 Start watching this issue