[SERVER-71938] Avoid applying commitTransaction entry individually if it refers to a prepare entry in the same batch Created: 07/Dec/22 Updated: 30/Mar/23 Resolved: 30/Mar/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Wenbin Zhu | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
With the current design, when the oplog batcher decides a commitTransaction oplog entry needs to be applied individually (OplogBatcher::mustProcessIndividually), it will check if the commitTransaction entry refers to a session in the SplitPrepareSessionManager, and will process it individually if not. However if the commitTransaction entry and the prepare entry it refers to come from the same batch, this check will always fail since we have yet called SplitPrepareSessionManager to split the session at this point. This results in us unnecessarily apply certain commitTransaction entries in their own batch, although it's not very common to have the commitTransaction entry and the prepare entry it refers to coming from the same batch because the prepare must be majority committed before the commit command is run. To avoid this, the oplog batcher needs save some state (either setting in itself or in SplitPrepareSessionManager) when it sees a prepare entry to indicate that there is a prepare to be split, and later when it sees a following commitTransaction entry in the same batch, it knows that it refers to a to-be-split prepare and that we can put it in the same batch with the prepare entry. |
| Comments |
| Comment by Wenbin Zhu [ 30/Mar/23 ] |
|
We are not going to group commits/aborts with other prepares, closing. |
| Comment by Wenbin Zhu [ 18/Jan/23 ] |
|
There is an additional caveat: once this is done, we could have multiple prepares for the same session in the same batch, e.g. [prepare, commit, prepare, commit]. When we dispatch the ops to the writer vectors, we need to call SplitPrepareSessionManager to create split sessions. However it currently disallows an already split top-level session to be split again without releasing. If we do this, we need to change that behavior to allow multiple splits on the same top-level session as long as they refer to different txnNumber's. |