-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
Repl 2019-03-11
The current plan for Prepare Support for Transactions uses an in-memory data structure to maintain the oldest active transaction timestamp. Instead, we can store the first oplog entry's timestamp of a transaction in the transaction table. Thus the transaction table has all necessary information to calculate the oldest active transaction timestamp. With SERVER-39679, this calculation may be done only when a checkpoint is taken or an initial sync starts, so its performance isn't a big concern. The updates on the transaction table are timestamped, so calculating the oldest require timestamp is just a read at the checkpoint's timestamp.
If table scan's performance isn't good enough, we can add an index on the "firstTimestamp" field. The index can be a partial index on "firstTimestamp" when a new "active: true" field exists, so that retryable writes and finished transactions don't affect the performance.
- is depended on by
-
SERVER-39792 Update the txn table for the first operation in a transaction on primary
- Closed
-
SERVER-40013 upgrade downgrade support for config.transactions startTimestamp field
- Closed
-
SERVER-40018 Remove ServerTransactionsMetrics::getOldestActiveOpTime
- Closed
- is duplicated by
-
SERVER-39828 Track the first timestamp of transaction in transaction table
- Closed
- is related to
-
SERVER-36494 Prevent oplog truncation of oplog entries needed for startup recovery
- Closed
-
SERVER-39679 Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp
- Closed
-
SERVER-39813 Add the oldest required timestamp into server status
- Closed
- related to
-
SERVER-39829 Consider in-progress transactions when calculating the oldest active transaction timestamp
- Closed
-
SERVER-39989 Use a config.transactions find command for the begin fetching timestamp in initial sync
- Closed