-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
Affects Version/s: 3.6.4, 3.7.9
-
Component/s: Sharding
-
Sharding EMEA
-
ALL
-
-
41
Let's say a (non-primary shard) recipient shard does not receive setShardVersion on dropCollection and it had cached chunks for the old collection in its config.cache.chunks.<ns>.
The first time it will refresh after the drop and recreate is when a chunk is being migrated to it (because recipient shards refresh at the beginning of _recvChunkStart).
On this refresh, it will see an epoch mismatch and query config.chunks with $gte 0|0. If this is the first chunk to be migrated in the new collection, the version of the chunk with the highest version in config.chunks will be 1|x. The recipient shard will persist this new chunk, but may not delete the "overlapping" (garbage) chunks from the previous collection if the shard key is different (see SERVER-34856).
The next time the recipient will refresh will be on a versioned request. Since its config.cache.chunks.<ns> contains garbage chunks, the one with the highest version will be used for querying config.chuns.
Since the control chunk is the one whose minor version is set to 1 (the migrated chunk's minor version is set to 0), the recipient shard may see only chunks that don't belong to it.
So, in all shardVersion checks, the recipient shard' its CSS will report that it does not own any chunks for the collection.
So, no versioned requests from a fresh mongos will succeed against the recipient shard.
- is related to
-
SERVER-34878 if setShardVersion for dropCollection not sent and collection re-created, migrations for new collection can fail indefinitely
- Closed