Info

Starting from binary version 4.7, the configTime component of the VectorClock is used both for readPreference and readConcern on read operations sent to the configServer. On the other hand nodes with FCV So as soon as the FCV 4.4 is set on the cluster we can't rely anymore on the vector clock and we should rather use the old configOpTime stored in the Grid. While shards are correctly relying on Grid::configOpTime() when the FCV is set thanks to this check, routers have no knowledge of FCV so the check will always pass and the last known VectorClock's configTime is going to be used (if greater than zero). These are two possible solutions I was thinking about: Use always the maximum between the old configOpTime and the new VectorClock[configTime] until we completely get rid of the former (v5.1). This should be a quick fix. Use always the old configOpTime until we can completely switch to the new VectorClock[configTime]  (v5.1). Also this one is a quick one. Actually I'm not sure why we already started using the new VectorClock[configTime] if it is still unreliable. Update the VectorClock[configTime] every time the old configOpTime is advanced. Also this should be quick one but it requires to mess a bit the code of the VectorClock.

Top User Comments

ian@10gen.com commented on Mon, 4 Jan 2021 21:58:53 +0000: Author: {'username': u'evrg-bot-webhook', 'name': u'Tommaso Tocci', 'email': u'tommaso.tocci@mongodb.com'} Message:SERVER-53523 Do not use stale VectorClock on FCV 4.4 Branch:master https://github.com/mongodb/mongo/commit/c3cb41d5d88308632d2da0c3f0d047487c3b66c3 tommaso.tocci commented on Fri, 1 Jan 2021 12:21:56 +0000: Commit: https://github.com/mongodb/mongo/commit/c3cb41d5d88308632d2da0c3f0d047487c3b66c3

Steps to Reproduce