[SERVER-4582] detect data inserted directly into a shard server incorrectly Created: 29/Dec/11  Updated: 06/Dec/22  Resolved: 22/Jul/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Daniel Pasette (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-58730 Implement a barrier for disallowing d... Closed
Related
related to SERVER-58730 Implement a barrier for disallowing d... Closed
Assigned Teams:
Sharding
Participants:

 Description   

When changing from a non-sharded to a sharded deployment, it is easy to forget
to update all application components to connect through mongos instead of
connecting to a replica set. If this conversion is missed, it is possible for
an application to insert data into a sharded collection directly, bypassing
mongos. This can result in data being inserted into the incorrect shard.
Such data appears to disappear when sought through mongos: mongos will route
queries to the appropriate shard, and the data is not found there.

Shard servers are aware they are part of a sharded setup because of the
shardsvr startup flag. Therefore, they should be able to verify inserted data
is within the expected shard chunk key ranges for themselves, and complain
otherwise.



 Comments   
Comment by Scott Hernandez (Inactive) [ 29/Dec/11 ]

See the documentation for the shardsvr option in the config file – http://www.mongodb.org/display/DOCS/File+Based+Configuration

Comment by Chris Westin [ 29/Dec/11 ]

I've never seen any documentation that says shardsvr is optional.

Even so, the above suggests checking if shardsvr is on, that is all.

Comment by Scott Hernandez (Inactive) [ 29/Dec/11 ]

--shardsvr is optional but suggested, and doesn't currently work as a flag because of that.

If clients checked for a sharded version state (in memory once the shard server has received the first setShardVersion command) then it could reject writes on non-sharded connected but currently this is designed to allow direct access to shards via non-sharded clients. This is commonly used for distributed updates and other administrative tasks when the load balancer is off.

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