[SERVER-47359] ShardRegistry reload can race with RSM updates to ShardRegistry Created: 06/Apr/20 Updated: 29/Oct/23 Resolved: 15/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc2, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Janna Golden | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | KP44 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||
| Sprint: | Sharding 2020-04-20 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 115 | ||||||||||||
| Description |
|
During startup, the ShardRegistry stores all nodes in the initial config server string and then schedules its initial reload and the RSM begins to monitor the config server. During start up, if the RSM gets a topology change of type ReplicaSetNoPrimary, (meaning its only heard back from secondaries), it will update the ShardRegistry with this info and remove any nodes that are not yet confirmed. The following set of steps can lead to a ShardNotFound error: 1. ShardRegistry starts up with all config server nodes passed in the initial connection string. |
| Comments |
| Comment by Githook User [ 16/Apr/20 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: (cherry picked from commit 2ecb450c1a48775953160b50ae0ac6e9f0ae5723) |
| Comment by Githook User [ 15/Apr/20 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |