-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.6.3, 3.7.2
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
v3.6
-
Sharding 2018-04-23, Sharding 2018-05-07
-
25
Secondaries have an OpObserver on "config.cache.collections" to invalidate their in-memory routing table cache entry for the namespace whose routing table is being updated, if the oplog entry has field 'lastRefreshedCollectionVersion'.
Primaries write the 'lastRefreshedCollectionVersion' field when marking the config.cache.collections entry as done refreshing. However, they only write the major/minor versions of the collection version; that is, they do not include the epoch.
If a sharded collection exists with one chunk (e.g., collectionVersion=(1,0, epoch)), then is dropped, recreated, and re-sharded, but the best-effort setShardVersion for the drop fails, then the refresh after the shardCollection will persist lastRefreshedCollectionVersion=(1,0).
Since this is no different than the lastRefreshedCollectionVersion already in the config.cache.collections document, the oplog entry for this update will not include the 'lastRefreshedCollectionVersion' field, so the OpObserver on the secondary will not fire.
Also dianna.hohensee, shouldn't the primary write 'lastRefreshedCollectionVersion' when starting the refresh, so that the secondary invalidates its in-memory cache sooner?