[SERVER-28385] Do not allow different ShardId vs. Replica Set Id Created: 17/Mar/17  Updated: 06/Dec/22  Resolved: 19/Aug/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jordan Sumerlus Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Do Votes: 0
Labels: sharding-emea-large, sharding-product-sync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

In most cases MongoDB defaults the shard Id to be the same as the Replica Set Id. Ops Manager does not allow users to import a cluster that has shard Ids that are inconsistent replica set Ids.

However it appears there are certain cases where these can be changed, or where the customer can change manually. It seems the correct resolution is not to patch in Ops Manager, but to resolve at the source and not allow this to occur in the server.



 Comments   
Comment by Kaloian Manassiev [ 22/Mar/17 ]

Sharding itself actually does not default the shard id to be the same as the replica set name. We just generate consecutively increasing names like shard0000, shard0001, etc.

The only way I can think of that customer can change the shard id is by manually modifying the config.shards collection. This is a very bad idea which can have more severe consequences because it would leave orphaned chunks (the chunks reference the shard id).

That being said I like the idea of making the shard id the same as the replica set name, but I am not sure this is possible to do from backwards compatibility point of view. I am putting the ticket in 'Needs Triage' to discuss it with the team.

Generated at Thu Feb 08 04:17:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.