-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
Repl 2017-07-31, Repl 2017-08-21
-
0
Every time a node advances its lastAppliedOpTime, the new optime will be added to a list of potential stable timestamps. The actual stable timestamp will be the greatest timestamp in this list that is less than or equal to the replication commit point. Timestamps can be removed from the list of ‘potential’ stable timestamps after it is less than the current stable timestamp. i.e. when it is less than the replication commit point and there is at least one other timestamp in the list greater than it that is also less than or equal to the replication commit point.
Setting the 'stable' timestamp will tell WiredTiger what is a valid timestamp to take a checkpoint at.
- is depended on by
-
SERVER-30309 Have WiredTigerKVEngine implement StorageEngine::supportsRecoverToStableTimestamp
- Closed
-
SERVER-29215 Coordinate oplog truncate point with checkpoint timestamp
- Closed
-
SERVER-29494 WT validate should wait for explicit checkpoint
- Closed
- is related to
-
SERVER-30589 Don't add stable timestamp candidates when in master slave mode
- Closed
-
SERVER-30577 Clear list of stable timestamp candidates on Rollback and Initial Sync
- Closed
- related to
-
SERVER-30843 Use std::set::upper_bound when calculating the stable timestamp
- Closed
-
SERVER-30845 Avoid updating the stable timestamp in WiredTiger unnecessarily
- Closed