-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Fully Compatible
-
Execution Team 2023-02-20, Execution Team 2023-02-06
Secondary oplog application currently handles a chain of applyOps oplog entries for a large multi-document transaction. We would like to extend this process to also handle a chain of applyOps entries for a large batched writes. This would involve separate some of the logical session and txnNumber handling from extracting the chain of replicated operations.
The entry point to this process is currently in OplogApplierImpl for multi-doc transactions. The opsMap function mapping in oplog.cpp is still used for batched writes which are replicated as atomic applyOps entries. We would have to fold the atomic applyOps processing into OplogApplierImpl to take advantage of the applyOps chaining logic provided in part by the TransactionHistoryIterator class.
There is some overlap between this ticket and “use OplogApplierImpl to process batched writes”. If no further work is determined to be necessary to handle the multi-oplog format for batched writes, this ticket may be closed accordingly.
- is duplicated by
-
SERVER-70904 use OplogApplierImpl to process batched writes
- Closed
-
SERVER-70572 support applyOps oplog entry chaining for BatchedWriteContext
- Closed
- related to
-
SERVER-72723 support rollback for multi-oplog batched writes
- Closed
-
SERVER-76408 create feature flag for SERVER-70903
- Closed
-
SERVER-73211 add OpTime hasher for stdx::unordered_map and stdx::unordered_set
- Closed
-
SERVER-73847 add support for ReplSetTest nodeOptions in RollbackTest
- Closed