[SERVER-38876] Ensure secondary user operations cannot abort transactions being applied from the oplog Created: 07/Jan/19 Updated: 29/Oct/23 Resolved: 21/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.10 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | prepare_errors | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2019-01-28, Sharding 2019-02-25, Sharding 2019-03-25 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
If a user attempts to use a Session on a secondary for an operation that accepts a transaction number, that operation will check out the session. If the transaction number is greater than one in use by a secondary oplog application thread for the same session, then it could abort that secondary oplog application transaction. This could lead to a crash or data corruption. One way to fix this could be to prevent user operations on secondaries from checking out a session. Transactions and retryable writes are not allowed on secondaries, so this should be fine (an exception can be made for testing, though would maybe cause test failures). Alternatively reads outside of a transaction could be prevented from checking out a session since writes are already prevented on secondaries and secondary transactions are already prevented except for in test mode. |
| Comments |
| Comment by Githook User [ 21/Mar/19 ] |
|
Author: {'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 04/Feb/19 ] |
|
Per offline conversation with judah.schvimer, |
| Comment by Judah Schvimer [ 24/Jan/19 ] |
This is due to this uassert for if the transaction is prepared, correct? If so, then I think the invariant created by |
| Comment by Esha Maharishi (Inactive) [ 23/Jan/19 ] |
|
My understanding is that this:
would happen because TransactionParticipant::beginOrContinue for the request with the higher transaction number could result in calling TransactionParticipant::_abortTransactionOnSession through TransactionParticipant::_setNewTxnNumber (for either a retryable write or transaction). However, it's only possible to reach TransactionParticipant::beginOrContinue under a checked out session, meaning it's only possible for this to occur if secondary oplog application can check a Session back in with a transaction in progress. |