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

Shard can continue to accept reads for a dropped collection if shard failover happens during setShardVersion sent at end of dropCollection

    • ALL
    • Sharding 2020-07-13
    • 19

      The config server can target an old shard primary (that has yet to find out that there is a new shard primary) for setShardVersion.

      The old shard primary can step down while executing the setShardVersion and continue executing setShardVersion as a secondary as long as the stepdown occurs before here, because stepdown only kills operations that have taken a MODE_IX, MODE_S, or MODE_X lock. The old shard primary will then send _flushRoutingTableCacheUpdates to the new shard primary. If the new shard primary does not have an entry for the database in its CatalogCache, it will not schedule a collection refresh against the ShardServerCatalogCacheLoader, so the config.cache* entries for the dropped collection will not get deleted.

      After the _flushRoutingTableCacheUpdates returns, the old shard primary (now secondary) will think its filtering table is up to date and will continue to accept reads for the dropped collection (even if the collection has been recreated elsewhere), which violates causal consistency.

            Assignee:
            randolph@mongodb.com Randolph Tan
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: