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