Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-10144

check if our semantics on getlasterror w:<n> are consistent on a series of write operations

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • 2.4.4
    • Replication
    • None
    • ALL

    Description

      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"

      Attachments

        Activity

          People

            milkie@mongodb.com Eric Milkie
            dwight@mongodb.com Dwight Merriman
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: