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

Generated at Thu Feb 08 05:24:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.