[SERVER-14669] Updates/deletes on sharded collections shouldn't affect orphan documents Created: 24/Jul/14  Updated: 06/Dec/22  Resolved: 03/Feb/22

Status: Closed
Project: Core Server
Component/s: Sharding, Write Ops
Affects Version/s: 2.2.7, 2.4.10, 2.6.3
Fix Version/s: 5.3.0

Type: Bug Priority: Major - P3
Reporter: Jason Rassi Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Done Votes: 2
Labels: stop-orphaning-fallout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-30970 Don't allow single-updates that aren'... Backlog
related to SERVER-11746 Improve shard version checking for ve... Closed
related to SERVER-17585 Enforce shard version after yields on... Closed
is related to SERVER-29145 Filter out changes to documents not o... Closed
Assigned Teams:
Sharding EMEA
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding EMEA 2022-01-24, Sharding EMEA 2022-02-07
Participants:
Case:

 Description   

Multi-updates and multi-deletes on sharded collections affect orphan documents, and are counted in WriteResult / getLastError stats. Writes to sharded collections should not affect orphan documents.

Affects all currently-released versions.

var st = new ShardingTest({shards:2});
assert.commandWorked(st.getDB("admin").runCommand({enableSharding: "test"}));
assert.commandWorked(st.getDB("admin").runCommand({shardCollection: "test.foo", key: {_id: "hashed"}}));
assert.writeOK((new Mongo("localhost:30000")).getDB("test").foo.insert({_id:0}));
assert.writeOK((new Mongo("localhost:30001")).getDB("test").foo.insert({_id:0}));
var res = st.getDB("test").foo.update({}, {$set: {a: 1}}, {multi: true});
assert.writeOK(res);
assert.eq(1, res.nMatched); // fails with [1] != [2]
res = st.getDB("test").foo.remove({});
assert.eq(1, res.nRemoved); // fails with [1] != [2]



 Comments   
Comment by Sergi Mateo Bellido [ 03/Feb/22 ]

This issue has been fixed in the context of PM-2423 and it will be available in 5.3 and newer versions.

Comment by Andy Schwerin [ 13/Apr/18 ]

Changing this behavior would require, at least for updates, substantial changes to either the chunk migration or routing table protocols.

Comment by Asya Kamsky [ 06/Sep/17 ]

On update that's not targeted by shard key to a single shard, this happens on non-multi update as well:

// bar is sharded on {x:1}
> db.bar.update({_id:5},{$inc:{y:1}})
WriteResult({ "nMatched" : 2, "nUpserted" : 0, "nModified" : 2 })

Comment by Asya Kamsky [ 06/Sep/17 ]

(if the shard key is not included in the query predicate)

My testing shows that it applies when shard key is in the query predicate if the predicate applies to the orphan documents.

Comment by Henrik Ingo (Inactive) [ 07/Oct/16 ]

Use case related comment: When tailing an oplog on a sharded cluster, it is unfortunate that updates and deletes to documents that "aren't really there" get logged. It seems impossible for the application tailing the oplog to know or filter out such "orphan updates".

Ref: https://www.mongodb.com/blog/post/pitfalls-and-workarounds-for-tailing-the-oplog-on-a-mongodb-sharded-cluster

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