[SERVER-27077] Do not attempt to reload ShardRegistry on CSRS until after replset is initialized Created: 16/Nov/16 Updated: 06/Dec/22 Resolved: 21/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.4.14, 3.6.23, 4.0.27, 5.0.3, 4.4.9, 4.2.17 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | ShardingRoughEdges | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding EMEA
|
| Sprint: | Sharding 2017-01-02 |
| Participants: |
| Description |
|
The ShardRegistry reload ends up failing and logging verbosely (see below). When reloading the shards through ShardLocal, RecoveryUnit::setReadFromMajorityCommittedSnapshot() returns ErrorCodes::ReadConcernMajorityNotAvailableYet: This happens even if replSetInitiate is called as long as it doesn't complete, for example as in BF-3957. Steps to repro: Run:
Example output:
|
| Comments |
| Comment by Kaloian Manassiev [ 21/Oct/21 ] |
|
The impact of this ticket is very small and the fix is not trivial, so we are closing it. |
| Comment by Kaloian Manassiev [ 12/Oct/21 ] |
|
From looking at one of the latest evergreen runs, it looks like the logging is still happening. Putting this ticket back in Needs Triage, so we can decide whether it is worth investing the time to improve the behaviour. |