[SERVER-28289] make shards verify that they are present in the config.shards of the cluster their shardIdentity points to Created: 13/Mar/17 Updated: 27/Oct/23 Resolved: 04/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.4.2, 3.5.4 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding 2017-05-08 | ||||||||
| Participants: | |||||||||
| Description |
|
While debugging a customer issue with ChrisHarrisHP, we found that it's fairly easy to attempt to make a backup cluster from a snapshot of a production cluster without deleting the shardIdentity doc from the backup shards. The backup cluster's shards will have the production cluster's config server connection string in their shardIdentity docs, so they will connect to the production cluster's config servers on startup without complaint. (We want them to instead connect to the backup cluster's config servers). It would help in catching this issue if shards were able to verify they were part of config.shards as part of sharding initialization. I can imagine this being tricky, though, because it might involve comparing connection strings, which we try to avoid. We can't compare shardIds, because the backup shard and production shard will have the same shardId in their shardIdentity. They will only differ in their host/port. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 04/May/17 ] |
|
Closing as Works As Designed but with documentation changes needed. The necessary changes are described in the 'Documentation Changes Summary' field. |
| Comment by Crystal Horn [ 28/Mar/17 ] |
|
Create Docs ticket and close this tickets. |
| Comment by Esha Maharishi (Inactive) [ 13/Mar/17 ] |
|
It doesn't help to check the shardId, because the backup shard and production shard will have the same shardId (and probably also replica set name). |
| Comment by Kaloian Manassiev [ 13/Mar/17 ] |
|
Can we just check the ShardId and possibly the replica set name without checking the full connection string? |
| Comment by Esha Maharishi (Inactive) [ 13/Mar/17 ] |
|
It's also tricky because if you want to move a shard to a different host/port, this would prevent the shard from being able to re-join the cluster seamlessly from the new location. It would require removeShard()'ing it, starting it up on the new host/port, and addShard()'ing it. |