[SERVER-38866] Ensure that secondaries correctly pin the stableTimestamp when there are prepared transactions Created: 06/Jan/19  Updated: 29/Oct/23  Resolved: 06/Feb/19

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

Type: Improvement Priority: Major - P3
Reporter: Pavithra Vetriselvan Assignee: Jason Chan
Resolution: Fixed Votes: 0
Labels: prepare_durability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-38620 prepareTransaction call doesn't set _... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-02-11
Participants:
Linked BF Score: 50

 Description   

We write the prepare oplog entry here, but this only occurs on the primary. On a secondary, the prepareOpTime would be null.

This could be a problem on secondaries because the stableTimestamp would always move forward, causing us to possibly commit a transaction before the stableTimestamp.



 Comments   
Comment by Githook User [ 06/Feb/19 ]

Author:

{'name': 'Jason Chan', 'email': 'jason.chan@10gen.com'}

Message: SERVER-38866 Change commitOplogEntryOpTime from std::optional to boost::optional
Branch: master
https://github.com/mongodb/mongo/commit/0875b7870fe0f435337589c2f73ef7011a93f5eb

Comment by Githook User [ 06/Feb/19 ]

Author:

{'name': 'Jason Chan', 'email': 'jason.chan@10gen.com'}

Message: SERVER-38866 Pass finishOpTime into commitPreparedTransaction on secondaries.
Branch: master
https://github.com/mongodb/mongo/commit/4d09b2e0a605aefd7adefda28e01e309bbf30883

Comment by Jason Chan [ 04/Feb/19 ]

Confirmed with pavithra.vetriselvan that SERVER-38620 addresses the issue with prepareOpTime being null on secondaries. This ticket will instead be used to track allowing _finishOpTime to be set on secondaries. Currently, the _finishOpTime is set here but getLastOp is not set on secondaries.

The initial approach is to grab the _finishOpTime and pass it as an optional parameter into commitPreparedTransaction from applyCommitTransaction. For testing, it should be sufficient to confirm the behavior in unit tests with the already existing getFinishOpTimeForTest in transaction_participant.h.

CC: judah.schvimer

Comment by Siyuan Zhou [ 08/Jan/19 ]

For larger than 16MB project, I guess we still need to track finishTime to know which transactions are active even when stable timestamp doesn't rely on this.

Generated at Thu Feb 08 04:50:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.