[SERVER-39792] Update the txn table for the first operation in a transaction on primary Created: 25/Feb/19 Updated: 29/Oct/23 Resolved: 25/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: | Gregory McKeon (Inactive) | Assignee: | Jason Chan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | bigtxns_recovery | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2019-03-11, Repl 2019-03-25, Repl 2019-04-08 | ||||||||
| Participants: | |||||||||
| Description |
|
We should set the state of the transaction in the transaction table to “in-progress” when we receive the first operation in a transaction on primary. |
| Comments |
| Comment by Githook User [ 25/Mar/19 ] |
|
Author: {'email': 'jason.chan@10gen.com', 'name': 'Jason Chan', 'username': 'jasonjhchan'}Message: |
| Comment by Jason Chan [ 19/Mar/19 ] |
|
judah.schvimer yes, I mean't to say the 'o' field of the prepareTransaction oplog entry specifically. Although, with siyuan.zhou's comment, it seems that it may make more sense to use $set to update the txn table rather than adding an extra field to the prepareTransaction oplog entry. |
| Comment by Judah Schvimer [ 19/Mar/19 ] |
jason.chan, do you mean the prepareTransaction oplog entry? |
| Comment by Tess Avitabile (Inactive) [ 18/Mar/19 ] |
|
A $set of a single field should not be noticeably slower than document replacement for small documents. The update system code might be slightly slower, since we need to scan the document to find the field to modify, but the WT implementation can be more efficient, since the WT update chain can just store the modified field instead of the whole document. Since the config.transactions document is small, the performance should be about the same. |
| Comment by Siyuan Zhou [ 18/Mar/19 ] |
|
Great summary! I initially preferred option 1 since it's more explicit and has a smaller scope, but when considering future possible format change, like ops packing, we'd have to include the startTimestamp in the applyOps with prepare field or make it use partial updates eventually. Thus, if $set isn't noticeably slower than document replacement, perhaps it make more sense not to require prepareTransaction or the packed applyOps format know the startTimestamp. CC tess.avitabile for the performance of $set. |
| Comment by Jason Chan [ 18/Mar/19 ] |
|
siyuan.zhou 2. On secondary application, set the startTimestamp to be the timestamp of the first transaction operation (the prevOpTime will be set to null here) when we encounter it. This may require us to change from updating the entire txn table entry at a time to only doing partial updates so we don't overwrite the startTimestamp when processing the sequence of derived ops to the txn table. Since there already exists a precedent of including timestamps in transaction commands (commitTimestamp in commit for prepared transactions), I was wondering if there are any strong objections to option 1? Thoughts? judah.schvimertess.avitabile |