[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:
Depends
depends on SERVER-47914 Move clusterTime from LogicalClock to... Closed
is depended on by SERVER-29729 remove afterOpTime readConcern argument Backlog
Duplicate
duplicates SERVER-50675 Get rid of Grid's configOpTime after ... Closed
Related
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:

 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 SERVER-50675 made it so the term component of the config server's optime is no longer gossiped between shards.

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. 

Generated at Thu Feb 08 05:05:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.