-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
Affects Version/s: 3.7.9
-
Component/s: Sharding
-
Sharding EMEA
-
ALL
-
-
27
Let's say the setShardVersion for dropCollection is not sent, and the collection is re-created (and re-sharded). This means the old chunks remain as garbage in the shard's config.cache.chunks.<ns>. (This is because the shard will not refresh after the drop. If it had, it would have seen the collection had been dropped and scheduled a task to drop its local config.cache.chunks.<ns> collection).
The setShardVersion for shardCollection for the new collection will cause the shard to refresh and find the new collection entry. Since the epoch is different from the collection entry in the shard's config.cache.collections, the shard will query for chunks with version $gte 0|0|<new epoch>.
The shard will find the chunk for the new collection and persist it in its config.cache.chunks.<ns>, alongside the garbage chunks. As part of this, the shard will attempt to delete chunks in config.cache.chunks.<ns> with ranges that "overlap" the new chunk.
However, the old chunks may not get deleted if their shard key sorts as "less than" the new shard key (see SERVER-34856).
. . .
Now, at the beginning of a migration, the donor shard forces a refresh.
The refresh queries config.chunks for chunks with version $gte the highest version of any chunk persisted on the shard in config.cache.chunks.<ns> (notice that the new collection's epoch is not included in the local query).
If there is a garbage chunk with a major version greater than 1 (that is, at least one migration had occurred), then it will be returned by the local query and its version will be used as the $gte for the remote query. So, the remote query will find no chunks.
The ShardServerCatalogCacheLoader will return ConflictingOperationInProgress, which will cause the CatalogCache to retry the refresh 3 times and get the same result.
Once the retries are exhausted, the donor will fail the moveChunk command with ConflictingOperationInProgress.
- related to
-
SERVER-34904 recipient shard may be unable to accept versioned requests if it doesn't receive setShardVersion for drop and collection is recreated
- Closed