[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.

Generated at Thu Feb 08 06:11:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.