[SERVER-49970] Prefer the VectorClock's ConfigTime to configOpTime when querying config servers Created: 29/Jul/20 Updated: 29/Oct/23 Resolved: 01/Sep/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Pierlauro Sciarelli |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-1645-Milestone-3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Sprint: | Sharding 2020-09-07 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently, querying the config servers still uses configOpTime() for the readConcern afterOpTime. However, if there is an initialized value (ie. not kUninitialized) for the VectorClock's ConfigTime component (and FCV is initialised and indicates kVersion451 or later), then that should instead be used (with afterClusterTime, not afterOpTime). (For upgrade/downgrade purposes, if these conditions are not met, then the server should fall back to the existing behaviour of configOpTime() for afterOpTime.) configOpTime() is also used for the readPreference minOpTime (here and here). It's not clear what should be done about these (since configOpTime() is to eventually be replaced by ConfigTime), but SERVER-46499 should help guide this. |
| Comments |
| Comment by Githook User [ 01/Sep/20 ] |
|
Author: {'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}Message: Co-authored-by: Pierlauro Sciarelli <pierlauro.sciarelli@mongodb.com> |