[SERVER-37929] ShardRegistry in config servers can keep invalid entries after it rolls back until next reload Created: 05/Nov/18 Updated: 29/Oct/23 Resolved: 13/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.1.4 |
| Fix Version/s: | 4.1.7, 4.0.19 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Misha Tyulenev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||
| Sprint: | Sharding 2018-12-17 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
When config server rollbacks data its ShardRegistry that is used for targeting gets out of sync. Instead, it should immediately call reload to avoid the inconsistent state. |
| Comments |
| Comment by Githook User [ 27/Apr/20 ] |
|
Author: {'name': 'Misha Tyulenev', 'email': 'misha@mongodb.com', 'username': 'mikety'}Message: (cherry picked from commit fc1b17cfdeffa13b5326050893658e7ba4df57a1) |
| Comment by Githook User [ 13/Dec/18 ] |
|
Author: {'username': 'mikety', 'email': 'misha@mongodb.com', 'name': 'Misha Tyulenev'}Message: |
| Comment by Judah Schvimer [ 03/Dec/18 ] |
|
Looks good with jack.mulrow's suggestions. |
| Comment by Jack Mulrow [ 03/Dec/18 ] |
|
misha.tyulenev SGTM. I think that method is only called by the rollback to a WiredTiger checkpoint code path, so we'll also want to reload the registry at the end of the other rollback code path here (rollback via refetch). Also, it looks like all configsvr commands set their ReadConcernArgs opCtx decoration read concern level to kLocal (e.g. _configsvrAddShard), so we'll want to do that when reloading as well. |