-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: 2.4.4
-
Component/s: Replication
-
None
-
ALL
This is sort of a QA and design question – and if found to be wrong then woudl be a bug.
Some users send a series of writes (w1, w2, w3, w4, w5, ..., w n) (on one connection) to a single replica set, and then after the series, call
{ getLastError:1, w:3 }for example. The assumption by the user is that when this is acknowledges, all writes through wn are propogated, including earlier writes like w5.
However, suppose the write w n was a "no-op", such as
db.foo.remove( { _id : "DNE" } ) // assume there is no "DNE" in the collection...
or
db.foo.update( { _id : "DNE" } , ... )
In these cases wn is not placed in the oplog on the primary.
A couple of questions:
(1) If after w n I call getLastError with w=3 (or majority etc.), am I assured w2 and the others have propogated?
Based on a simple test (below), it appears the the answer is yes. So perhaps all is fine.
(2) What about sharded? (2a) What is the contract for sharded? (2b) And what happens, and is it correct?
x:PRIMARY> // this is a one member replica set x:PRIMARY> db.foo.insert({}) x:PRIMARY> db.foo.remove({x:3333}) // this does not appear in the oplog -- perhaps that is a good thing x:PRIMARY> db.getLastError(2) // hangs forever, as one would want, indicating question #1 behaves "nicely"
- related to
-
SERVER-10037 Optimize updates when document is unchaged
- Closed