[SERVER-15551] Add a mongod mode to simulate sharded cluster constraints Created: 07/Oct/14 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | AdiZ | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
So long as there are features that are prohibited, limited, or that underperform on a sharded cluster, it might be nice to let people spin up standalones and replica sets that prohibit or warn about the use of those features, so that the developer can ensure that they're not relying on features they'll have to give up when they choose to shard. I'd envision this as a command-line flag that either disallows or logs when an application tries something that doesn't play well with sharding. Broadly speaking, there are three categories of things I could imagine flagging
For the last two to work, it'd be necessary to configure a mongod that was started in the appropriate mode with fake shard key definitions for some collections. I have no opinions about how that ought to work, other than that it'd be nice for such fake shard key definitions to be both persistent and easy to delete in a non-sharded mongod. Observation: even if the general "fake sharding mode" idea were implemented piecemeal (i.e., not everything that ought to be caught were for initial iterations), it might still be incrementally useful. Documentation changes needed: if implemented, must be documented. CAP Verification: if implemented, then it ought to be tested. |