[SERVER-31414] The writes of _configsvrEnableSharding to config.databases do not use local write concern Created: 05/Oct/17 Updated: 06/Dec/22 Resolved: 22/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | ShardingTechDebt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 36 | ||||||||||||
| Description |
|
ShardLocal is given a Shard::RetryPolicy::kIdempotent retry policy for the config.databases write, where WriteConcernError is a retryable error (see remote_command_retry_scheduler.cpp. However, it runs into a DuplicateKeyError when it retries the write. See BF-6713 for details of the failure. I hypothesize that the issue is that ShardLocal/CatalogClient uses majority write/read concern, and instead it should use local and then mongos should call _configsvrEnableSharding with majority write concern so it waits after the write. Might want to make sure the mongos can deal with the WriteConcernError properly, so the config stepdown suite doesn't fail loudly. |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 05/Oct/17 ] |
|
Another proposal is to change the idempotent retry policy to no retry policy, when run on config servers. Easier, less correct. |