[SERVER-36589] Implement mongos abort logic Created: 10/Aug/18 Updated: 29/Oct/23 Resolved: 26/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Randolph Tan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ShardedTxn:RouterSupport | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2018-08-27, Sharding 2018-09-10, Sharding 2018-09-24, Sharding 2018-10-08 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently, mongos aborts transactions by sending abortTransaction to all shards, since this was sufficient for the single shard case. Instead, it should be changed to only target the shards in the participant list that have been successfully sent startTransaction=true. Mongos should also remember if a txnId (lsid/txnNumber pair) is aborted, so it won't accept more statements for a transaction after it chooses to abort. |
| Comments |
| Comment by Githook User [ 01/Oct/18 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 26/Sep/18 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: |
| Comment by Githook User [ 26/Sep/18 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: |
| Comment by Jack Mulrow [ 05/Sep/18 ] |
Sounds good to me, as long as we stop sending abort to all shards in the cluster like we do now. That's all I really meant in the description.
You may not have seen this, but to allow internal retries by mongos, I had to make shards accept startTransaction=true at their active transaction number, even if the shard aborted that transaction number already (
|
| Comment by Randolph Tan [ 05/Sep/18 ] |
I think it should sent abort regardless of whether mongos has been successfully startTxn or not since it cannot guarantee that the shard failed to execute when mongos gets an error.
I'm not fully convinced that this is 100% correct. On the other hand, I believe that it is safe allowing new statements to get executed since it will never succeed in running on the shards that aborted and the whole transaction will never be able to commit if at least one participant aborted already. I'm going to defer this "nice to have" optimization for later work. |