[SERVER-68749] Need to persist the catalogShard field in config.shards Created: 11/Aug/22  Updated: 29/Oct/23  Resolved: 15/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Andrew Shuvalov (Inactive) Assignee: Andrew Shuvalov (Inactive)
Resolution: Fixed Votes: 0
Labels: sharding-nyc-subteam2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-68700 config.shards not updated on reconfig... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2022-09-05
Participants:
Story Points: 3

 Description   

Added this field to ShardType for SERVER-68700 but it's not persisted.



 Comments   
Comment by Andrew Shuvalov (Inactive) [ 12/Aug/22 ]

There are multiple small reasons for this, none of them is absolute must but all together seems beneficial:
1. Uniformity, there should be an easy way to just tell this shard is special
2. Eventually will be needed for discovery, even if we don't do it now
3. Make ShardRegistry tight, right now it stores 2 shards - one with config name and another with custom name, and no way to tell this is the same shard
4. The 'isConfig()' on catalog shard with custom name currently returns false, however it is config
5. Fix that 'reconfig' problem, while the right fix with making the shard to update CSRS will be done later

Comment by Kaloian Manassiev [ 12/Aug/22 ]

Just curious - what is the logic for persisting the catalog shard field in config.shards? Is it just for uniformity with the rest of the shards or does it have to do with discovery?

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