[SERVER-53523] Do not use stale VectorClock on FCV 4.4 Created: 24/Dec/20 Updated: 29/Oct/23 Resolved: 01/Jan/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.7.0 |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | Tommaso Tocci |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Linked BF Score: | 14 | ||||
| Description |
|
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 <= 4.4 are not gossiping this component of the vector clock. 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:
|
| Comments |
| Comment by Ian Whalen (Inactive) [ 04/Jan/21 ] |
|
Author: {'username': u'evrg-bot-webhook', 'name': u'Tommaso Tocci', 'email': u'tommaso.tocci@mongodb.com'}Message: |
| Comment by Tommaso Tocci [ 01/Jan/21 ] |
|
Commit: https://github.com/mongodb/mongo/commit/c3cb41d5d88308632d2da0c3f0d047487c3b66c3 |