[SERVER-49777] Change _currentCommittedSnapshot to be a timestamp instead of an optime Created: 21/Jul/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-49732 Change _currentCommittedSnapshot to b... Closed
related to SERVER-35344 Stable timestamp and _currentCommitte... Backlog
Assigned Teams:
Replication
Participants:

 Description   

Currently, the _currentCommittedSnapshot is stored as an optime, which requires us to construct a term for it in certain cases when we don't set it based on a real optime in the oplog. This makes the stable timestamp calculation more complex than necessary, since the stable timestamp doesn't require any term information. We should consider refactoring the currentCommittedSnapshot to be a Timestamp, so that we don't need to construct a "virtual" optime. This would likely require re-wiring certain aspects of how we do write concern waiting logic, and may require some changes to how we provide this value as the "config optime" to sharding.

Fundamentally, a timestamp should include sufficient information for the purposes that the committed snapshot is used for i.e. majority readers only use a timestamp for reads, and when waiting for an operation to commit at a certain write concern, timestamps should be sufficient to totally order operations in a local node log, so inclusion of the term shouldn't be strictly necessary.



 Comments   
Comment by William Schultz (Inactive) [ 21/Jul/20 ]

This is an optional improvement ticket, whereas SERVER-49732 is a more urgent bug fix, which should likely be done before this, since this change may require some more thoughtful refactoring.

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