-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Storage
-
Fully Compatible
-
Repl 2019-03-11, Repl 2019-03-25, Repl 2019-04-08
Due to Prepare Support for Transactions and Larger Transactions Than 16MB, we cannot truncate transaction oplog entries if their commit oplog entry isn't stable yet.
The current solution is to pass the current oldest active transaction to setStableTimestamp(), so that we have to read the oldest active transaction at the stable timestamp, the oldest required timestamp, every time we set the stable timestamp. To save this read, we could let the storage layer call back the replication system when it's about to start a checkpoint. Replication will read the oldest required timestamp or calculate this timestamp in other ways, then return the timestamp to storage. After the checkpoint, storage uses the oldest required timestamp to let oplog truncation thread know where it can truncate up to.
Passing the oldest required timestamp to storage can be done asynchronously if that makes storage work easier.
- is depended on by
-
SERVER-36494 Prevent oplog truncation of oplog entries needed for startup recovery
- Closed
- is related to
-
SERVER-36811 Provide a mechanism for replication to specify the 'maximum_truncation_timestamp' for a given 'stable_timestamp'
- Closed
- related to
-
SERVER-58184 Checkpoint thread causes assertions when raced with recovering prepared transactions on startup
- Closed
-
SERVER-36772 Ensure oplog cannot be truncated due to capped deletions in standalone mode
- Closed
-
SERVER-39680 Maintain the oldest active transaction timestamp only with the transaction table
- Closed