[SERVER-39438] Write "abort" oplog entry when aborting unprepared transaction with replicated operations Created: 08/Feb/19  Updated: 29/Oct/23  Resolved: 14/May/19

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

Type: Task Priority: Major - P3
Reporter: Siyuan Zhou Assignee: Jason Chan
Resolution: Fixed Votes: 0
Labels: bigtxns_packing, bigtxns_perf
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-73131 clarify cached partial transaction op... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-05-06, Repl 2019-05-20
Participants:

 Description   

We are exposing in-progress transactions in the oplog for large transactions. Due to the requirement of Oplog Maintenance, it becomes necessary to expose the entire lifetime of transactions, including abort, to secondaries. Thus we need to always write an abort oplog entry whenever an in-progress unprepared transaction with replicated operations is aborted. Prepared transactions are already aborted with an oplog entry.



 Comments   
Comment by Githook User [ 14/May/19 ]

Author:

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

Message: SERVER-39438 Write "abortTransaction" oplog entry when aborting unprepared transactions with replicated operations
Branch: master
https://github.com/mongodb/mongo/commit/02b4ea3a929731cb34a3eeb3190051da42e1f2d3

Comment by Jason Chan [ 23/Apr/19 ]

As part of this ticket, we should also finish up this TODO to change the conditional into an invariant.

Comment by Siyuan Zhou [ 14/Feb/19 ]

As tess.avitabile pointed out, if the oplog entries are written in a single WUOW, we don't have to write an "abort" oplog entry on unprepared "commit" or "prepare" failures, so I'm reprioritizing this ticket. We will need this if we decided to split the single WUOW into smaller ones for performance reason.

Comment by Siyuan Zhou [ 14/Feb/19 ]

As pointed by tess.avitabile, if we cannot write an abort oplog entry, then we must fassert, unless we are no longer primary.

Comment by Siyuan Zhou [ 13/Feb/19 ]

As part of this ticket, we should use OperationContext::runWithoutInterruption(Callback&& cb) to wrap the call into OpObserver::onTransactionAbort() since writing the "abort" oplog entry may fail otherwise due to interruption.

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