Info
In view_rewrite.js, the test enables sharding on a database and then shards a collection. Sharding a collection requires the database have sharding enabled. However, this can fail under unusual circumstances when a stepdown occurs between enabling sharding on the database and sharding the collection; the write to the config server indicating that the database has sharding enabled may no longer be visible (though it is guaranteed to eventually become visible).
Top User Comments
kaloian.manassiev commented on Thu, 26 Mar 2020 08:56:32 +0000:
Thanks for the detailed write-up, kevin.pulo. Yes, the reasoning sounds right, because the local read concern will permit the write to be seen even though it is not yet majority committed and any decision (i.e., subsequent write) made based on that read will be majority committed.
This looks like it's gone away.
kevin.pulo@10gen.com commented on Thu, 26 Mar 2020 08:06:08 +0000:
I'm 99% sure this was fixed by SERVER-30615 (and later further strengthened by SERVER-32375), which adjusted ShardLocal to do these local configsvr reads with readConcern level of local, rather than majority (as it was when this ticket was filed). This means that the enableSharding op isn't hidden by reading from the slightly-old majority snapshot. This was the approach taken at the time, rather than trying to do afterOpTime/afterClusterTime majority reads, to solve similar visibility problems when stepdowns occurred between sequential sharding operations. This would also explain why there haven't been any recent recurrences of this problem, since SERVER-30615 was fixed about a month after this ticket was filed.
