[SERVER-36853] Coordinator should resume coordinating commit for unfinished transactions on stepup Created: 24/Aug/18 Updated: 29/Oct/23 Resolved: 11/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ShardedTxn:DistributedCommit, transaction-coordinator-management | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2018-10-22, Sharding 2018-11-05, Sharding 2018-11-19, Sharding 2018-12-17 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||
| Description |
|
Server changes:
If this ticket is completed before "prepare" is ready for failover testing, additional server changes:
These overrides should be removed under Testing
|
| Comments |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Esha Maharishi', 'email': 'esha.maharishi@mongodb.com', 'username': 'EshaMaharishi'}Message: |
| Comment by Githook User [ 11/Dec/18 ] |
|
Author: {'name': 'Esha Maharishi', 'email': 'esha.maharishi@mongodb.com', 'username': 'EshaMaharishi'}Message: |
| Comment by Kaloian Manassiev [ 29/Nov/18 ] |
|
The proposed implementation looks good, just a couple of questions: For 1.1 above - this all will happen in the onDrainComplete phase, right? I believe creating a new coordinator doesn't take any locks, can you remind me how issuing a new 'coordinateCommit' request against a primary will serialize with that recovery process so that in the end the transaction coordinator on the catalog reflects what's on disk, because I think in this case replication will accept PrimaryOnly requests from what I remember? For the transaction participant, this is ensured by the checkoutSession mechanism. For 1.2 above - this will happen when the drain mode is completed, right? Remind me why do we need to join and not just leave it to the commit pipeline to run in the background. |