I was able to reproduce this with both Java and Python drivers (as well as shell). It requires starting a new connection/process.
To reproduce, create two shards. Insert some data into a collection sharded on _id. Split into two chunks. Move chunk containing _id: X to a different shard through mongos on 57018 (different than what test program uses).
Now an update to ({_id:X}, {$set:{whatever}}) will return GLE:
(in Java):
{
"serverUsed" : "localhost:57017",
"shards" : [
"asya/localhost:27017,localhost:27018,localhost:27019",
"localhost:37017"
],
"shardRawGLE" : {
"asya/localhost:27017,localhost:27018,localhost:27019" : {
"writeback" : {
"$oid" : "50c3f952000000000000011f"
},
"instanceIdent" : "Asyas-MacBook-Air.local:27018",
"n" : 0,
"lastOp" : {
"$ts" : 1355020595,
"$inc" : 1
},
"connectionId" : 33220,
"wtime" : 0,
"err" : null,
"ok" : 1
},
"localhost:37017" : {
"writeback" : {
"$oid" : "50c3f87100000000000005ba"
},
"instanceIdent" : "Asyas-MacBook-Air.local:37017",
"n" : 0,
"connectionId" : 62,
"wtime" : 0,
"err" : null,
"ok" : 1
}
},
"n" : 0,
"err" : null,
"ok" : 1
}
In Python I got the same thing. Basically, do a moveChunk (on a different mongos) to the other shard and run the little test program again - first time after chunk move it always returns this sort of document, n=0 and no updatedExisting even though the record gets updated.
- duplicates
-
SERVER-4532 GetLastError on sharded cluster can report incorrect result
-
- Closed
-