[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:
Related
is related to SERVER-22895 mongos has inconsistent behavior for ... Backlog
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
in such a mode:

  1. features that mongos unconditionally refuses to route (e.g., db.eval, $snapshot queries, $isolated updates, etc.),
  2. features that are disallowed on sharded collections because they play poorly with sharding key (unique indexes, single-document updates, etc.)
  3. queries that don't incorporate shard keys. [This might be overly broad. Perhaps it ought to be queries that don't incorporate shard keys and that supply a limit and/or that use an index? Basically, things that are attempting to be selective (and so are presumably things for which users want or expect low latency), however that might be operationally characterized.]

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.


Generated at Thu Feb 08 03:38:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.