Description
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.
Attachments
Issue Links
- duplicates
-
SERVER-4532 GetLastError on sharded cluster can report incorrect result
-
- Closed
-