[DOCS-10229] Docs for SERVER-28289: make shards verify that they are present in the config.shards of the cluster their shardIdentity points to Created: 08/May/17 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Server |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Emily Hall | Assignee: | Ravind Kumar (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 14 weeks, 2 days ago | ||||||||
| Description |
Documentation Request Summary:We decided to just improve documentation in order to help customers avoid this issue. The recommended improvement is for the Restore a Sharded Cluster page. There are two restore procedures described on the page, and here are the recommended updates to each: For the "Restore a Sharded Cluster with Filesystem Snapshots" procedure (the first procedure on the page), first modify step 6.1 to specify "without the --shardsvr option", like so:
Then add a step between steps 6.2 and 6.3 that says:
For the "Restore a Sharded Cluster with Database Dumps" procedure (the second procedure on the page), add a step between steps 9 and 10 that says:
Engineering Ticket 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 Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |