[SERVER-44097] Remove term from config server opTime tracking Created: 18/Oct/19 Updated: 06/Dec/22 Resolved: 17/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Duplicate | Votes: | 2 |
| Labels: | max-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||||||||||
| Sprint: | Sharding 2019-11-04, Sharding 2019-11-18, Sharding 2019-12-16, Sharding 2020-01-13, Sharding 2020-02-10, Sharding 2020-03-09, Sharding 2020-03-23, Sharding 2020-04-06 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||
| Description |
|
Currently nodes in a sharded cluster gossip the latest known config server majority committed opTime and use it as an afterOpTime read concern argument when reading sharded metadata from the config server to guarantee a causally consistent view. All sharded metadata reads and writes are performed with majority read and write concern, so there should be no situation where a rollback can break the causal consistency of catalog operations and it should be safe to stop tracking the term. |
| Comments |
| Comment by Max Hirschhorn [ 17/Nov/21 ] |
|
Tommaso clarified for me that the changes from The shards still do their reads with afterOpTime using the timestamp component of the config server's optime but now use a term of -1. SERVER-29729 tracks changing the shards to use afterClusterTime for this purpose instead (and omit the dummy term entirely) but there isn't a functional difference. The behavior is identical in this case because kUninitializedTerm has the property of causing the term component to be ignored when comparing optimes. |
| Comment by Kaloian Manassiev [ 28/Apr/21 ] |
|
It did not resolve it, because we hit some bug on replica sets with how they handle OpTime without term, so we left it on the backburner. I am trying to gather the context now. |
| Comment by Andy Schwerin [ 27/Apr/21 ] |
|
garaudy.etienne, did PM-1645 resolve this? |
| Comment by Garaudy Etienne [ 18/Jun/20 ] |
|
PM-1645 should fix this issue but it will not be backported due to amount of work required to put it on older branches. |