|
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.
|
|
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.
|