[SERVER-22895] mongos has inconsistent behavior for replacement-style single-update with empty query Created: 29/Feb/16 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.3.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (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
|
|||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||
| Participants: | ||||||||||||||||||||||
| Description |
|
Mongos allows a replacement-style single-update with an empty query but an update containing the shard key to be executed on the shards. If the first document the update encountered by mongod contains the shard key, the update will be executed successfully. Otherwise, the mongod will return the following write error to mongos, which is passed to the client:
Therefore, the behavior of the update on a mongos depends on the order of documents seen by the mongod. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 07/Mar/16 ] | ||||||||||||||||||||||||||||||||||||||||
|
I feel like this is probably "works as designed", but we can discuss at our next triage meeting. | ||||||||||||||||||||||||||||||||||||||||
| Comment by Esha Maharishi (Inactive) [ 29/Feb/16 ] | ||||||||||||||||||||||||||||||||||||||||
|
Since replacement-style updates with an empty query are allowed on a single mongod, we can either:
or
| ||||||||||||||||||||||||||||||||||||||||
| Comment by Esha Maharishi (Inactive) [ 29/Feb/16 ] | ||||||||||||||||||||||||||||||||||||||||
|
I think it may be due to update processing on a mongod itself? On 2.6, 3.0, 3.2, and master, a replacement-style update with an empty query and upsert=false overwrites the first document it encounters with the replacement doc:
gives:
| ||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 29/Feb/16 ] | ||||||||||||||||||||||||||||||||||||||||
|
More importantly, it looks like for replacement-type updates the targeter targets based on the replacement document, but then the entity the invokes the targeter looks like it doesn't change its filter to include the shard key – if that even makes sense. Possible regression? | ||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 29/Feb/16 ] | ||||||||||||||||||||||||||||||||||||||||
|
Since we target on the replacement document, I think the only error here is that we didn't internally get "stale shard version" on the stale mongos, and refresh the chunk metadata. |