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

config.cache collections can remain even after collection has been dropped

    • Fully Compatible
    • ALL
    • v5.0
    • Hide

      see attached test.js

      see attached test.js
    • Sharding EMEA 2021-05-31, Sharding EMEA 2021-06-14, Sharding EMEA 2021-06-28
    • 20

      Which can lead to secondaries believing that collection is still sharded.


      • collection test.user is sharded
      • 1 shard, current primary: nodeA
      • shard's nodeB never heard about test.user, so it never had any catalog cache entries.

      1. _configsvrDrop deletes all config.chunks and config.collections.
      2. nodeA steps down, and nodeB becomes new primary.
      3. _configsvrDrop sends setShardVersion (0,0) to all shards. Since nodeB never had any entries, set shard version was a no-op.
      4. If secondary read with shard version comes to nodeA, it will try to ask nodeB (the primary) to refresh with _flushRoutingTableCacheUpdates.
      5. nodeB will end up calling getDatabase and load all sharded collections under that database, but since test.user is already dropped, it will be skipped.
      6. So nodeB will end up returning early without asking the CatalogCacheLoader to reload. The consequence is that since the catalog cache loader did not perform the reload, the config.cache collections for test.user will remain untouched.
      7. nodeA gets ok response from _flushRoutingTableCacheUpdates, and then tries to check the version via reading config.cache.chunks, and will find out that there are still documents and erroneously believe that collection is still sharded.

            antonio.fuschetto@mongodb.com Antonio Fuschetto
            randolph@mongodb.com Randolph Tan
            0 Vote for this issue
            8 Start watching this issue