[SERVER-73131] clarify cached partial transaction ops state in oplog applier when aborting a prepared transaction Created: 20/Jan/23 Updated: 29/Oct/23 Resolved: 23/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.3.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Benety Goh | Assignee: | Benety Goh |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Execution Team 2023-01-23 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
TLDR: enforce expectations on partialTxnOps in OplogApplierImpl::_deriveOpsAndFillWriterVectors(). The function OplogApplierImpl::_deriveOpsAndFillWriterVectors() is used during oplog application to extract embedded operations from transaction oplog entries (ie. applyOps) from the current batch of operations returned from the oplog batching/fetching logic. The partialTxnOps map caches operations for multi-oplog transactions within the current batch - partial transaction operations outside the current batch in the large transaction is retrieved from the oplog collection in _addOplogChainOpsToWriterVectors(). The batch processing logic currently clears the cached partial transaction operations when it encounters an abort transaction oplog entry in the same batch. Per current rules around oplog batch boundaries, especially with regards to OplogBatch::mustProcessIndividually()|https://github.com/mongodb/mongo/blob/1947ddfa0a6418ea1aae5fa720ffb43aa4b3a4e1/src/mongo/db/repl/oplog_batcher.cpp#L132], an abort transaction oplog entry must be the only operation in any oplog batch. It would be nice to clarify the logic in the oplog applier, preferably with an invariant on the expected state of partialTxnOps, when we attempt to process an abort for a prepared transaction. |
| Comments |
| Comment by Githook User [ 20/Jan/23 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: |
| Comment by Githook User [ 20/Jan/23 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: Note this unit test covers a scenario currently disallowed under current oplog batching rules. |
| Comment by Jason Chan [ 20/Jan/23 ] |
|
Copying from my conversation with Benety. From what I remember:
For extra context, one can refer to the design of packing oplog formats for large transactions. |