[SERVER-33879] config.transactions is not updated during startup replication recovery Created: 14/Mar/18 Updated: 29/Oct/23 Resolved: 04/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Sharding |
| Affects Version/s: | 3.6.3, 3.7.3 |
| Fix Version/s: | 3.6.5, 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Randolph Tan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | rollback-functional | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||||||||||||||||||
| Sprint: | Sharding 2018-04-09 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Linked BF Score: | 56 | ||||||||||||||||||||||||||||||||
| Description |
|
We call syncApply which does not internally call Session::addOpsForReplicatingTxnTable. This can lead to the transactions table missing entries if the server crashes before applying an entire batch. |
| Comments |
| Comment by Githook User [ 26/Apr/18 ] |
|
Author: {'email': 'randolph@10gen.com', 'username': 'renctan', 'name': 'Randolph Tan'}Message: (cherry picked from commit 3cd5682db00ced94fb79fcec0a9ceca22c48f4d9) |
| Comment by Githook User [ 04/Apr/18 ] |
|
Author: {'email': 'randolph@10gen.com', 'name': 'Randolph Tan', 'username': 'renctan'}Message: |
| Comment by Gregory McKeon (Inactive) [ 03/Apr/18 ] |
|
renctan can you make this your next work item? It's blocking repl from testing recoverable rollback's correctness. |
| Comment by Judah Schvimer [ 14/Mar/18 ] |
|
That suite does not kill nodes so replication recovery does not come into play. I filed |
| Comment by Randolph Tan [ 14/Mar/18 ] |
|
judah.schvimer We have the retryable passthrough suite |
| Comment by Judah Schvimer [ 14/Mar/18 ] |
|
Do we have retryable writes/transactions testing in jstests/core/? I'm trying to think about how to improve our test coverage of this such that the periodic kill secondaries passthrough would catch this. |
| Comment by Randolph Tan [ 14/Mar/18 ] |
|
kaloian.manassiev I don't think so. The issue is the code is calling syncApply (apply single operation) and the logic for updating config.transactions before and after |
| Comment by Kaloian Manassiev [ 14/Mar/18 ] |
|
renctan, could this have been introduced by your fix for |
| Comment by Judah Schvimer [ 14/Mar/18 ] |
|
This was discovered while debugging recoverable rollback, which makes this far more likely to occur. This might be fixed by |