[SERVER-68744] Shard should directly update config.shards on successful reconfig Created: 11/Aug/22 Updated: 05/Dec/22 Resolved: 03/Oct/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andrew Shuvalov (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | sharding-nyc-subteam2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding NYC
|
| Participants: |
| Description |
|
The update is currently made from Mongos in updateReplicaSetOnConfigServer(). This is just best effort. This probably has to be done from _doReplSetReconfig however it requires some effort. I see that the reconfig is still supported when the node is not a writable primary and in the case of catalog shard won't be able to do a replicated write. If we remove this logic from Mongos and have cases when it fails in mongod, it may become even worse. Perhaps kaloian.manassiev@mongodb.com has some ideas? |
| Comments |
| Comment by Andrew Shuvalov (Inactive) [ 18/Aug/22 ] |
|
Yes, need help, thanks. I did a simple fix just for our code to work but in general the Mongos doing the config.shards change on reconfig seems odd. The fix is not trivial though, this is why I want to ask for your help. |
| Comment by Tommaso Tocci [ 18/Aug/22 ] |
|
andrew.shuvalov@mongodb.com is this part of PM-2290? If so, do you need any help from the sharding EMEA team to complete it? |
| Comment by Cris Insignares Cuello [ 18/Aug/22 ] |
|
tommaso.tocci@mongodb.com to review it with kaloian.manassiev@mongodb.com |
| Comment by Kaloian Manassiev [ 12/Aug/22 ] |
|
For everything except the CatalogShard, every shard independently executes reconfig as part of its own replica set management, regardless of sharding. It is in response to this reconfig that the primary of that shard should be informing the CatalogShard that certain shards' replica set composition has changed. For the case of the CatalogShard, I don't think it is much different and also we don't really need to update that shard since it already is a replica set and if we managed to contact it, we know what is its composition. |