[SERVER-50995] Investigate resiliency to, or prohibition of, direct modifications to config.shards Created: 17/Sep/20 Updated: 27/Oct/23 Resolved: 12/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding
|
||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
it is currently possible to perform manual/direct modifications to documents in config.shards on a live sharded cluster, even though this is not supported and has undefined consequences, including rendering the cluster inoperable. We should investigate if we want to make the system tolerant of such changes (and if so, in what way), or if they should be completely disallowed on running systems. (Note that it should probably never be disallowed completely, since it is sometimes necessary in order to fix unexpected issues.) |
| Comments |
| Comment by Kaloian Manassiev [ 12/Oct/21 ] |
|
While such preventative measures are nice to have, the time investment in actually doing them and the risk of breaking some subtle Cloud dependency outweighs the potential benefits, so closing as WAD. |