[SERVER-36494] Prevent oplog truncation of oplog entries needed for startup recovery - MongoDB Jira

XML

Word

Printable

JSON

Backwards Compatibility:
Fully Compatible
Sprint:
Repl 2018-11-19, Repl 2019-02-11, Repl 2019-02-25, Repl 2019-03-11, Repl 2019-03-25, Service Arch 2019-04-22, Repl 2019-04-08
Linked BF Score:
0

depends on

SERVER-36811 Provide a mechanism for replication to specify the 'maximum_truncation_timestamp' for a given 'stable_timestamp'

SERVER-39679 Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp

is depended on by

SERVER-40457 test that secondaries roll over their oplogs when they exceed oplogSize

related to

SERVER-39627 Audit uses of TransactionParticipant::SideTransactionBlock

SERVER-36772 Ensure oplog cannot be truncated due to capped deletions in standalone mode

SERVER-38165 Test that prepared transactions work with an in-memory secondary

SERVER-39680 Maintain the oldest active transaction timestamp only with the transaction table

SERVER-39989 Use a config.transactions find command for the begin fetching timestamp in initial sync

SERVER-30460 Grow the oplog when the replication commit point falls behind the back of where it would normally be truncated to

(4 related to)

Participants:: A. Jesse Jiryu Davis, Githook User, Gregory McKeon, Judah Schvimer, Nate Brennand