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

mongod does not always include operationTime and clusterTime in responses

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      I've attached reproduce.sh which should show the behavior. It spins up a replica set with --keyFile but no --shardsvr and most of the time operationTime and clusterTime will be present in the first request made, but if not will appear in the second or third.

      It then spins up a replica set with --keyFile and --shardsvr, and operationTime and clusterTime will not be present in the response.

      Then it spins up a config replica set and a mongos, and adds the replica set as a shard, at which point operationTime and clusterTime will appear in the response.

      Show
      I've attached  reproduce.sh  which should show the behavior. It spins up a replica set with --keyFile but no --shardsvr and most of the time operationTime and clusterTime will be present in the first request made, but if not will appear in the second or third. It then spins up a replica set with --keyFile and --shardsvr , and operationTime and clusterTime will not be present in the response. Then it spins up a config replica set and a mongos , and adds the replica set as a shard, at which point operationTime and clusterTime will appear in the response.

      Description

      When a replica set is started with both --keyFile and --shardsvr, but is not yet added as a shard to a sharded cluster, the responses from the mongod do not contain either operationTime or clusterTime. Once the replica set is added as a shard, the fields begin being populated.

      For example, prior to being added as a shard, a response to db.runCommand({ find: 'repro', filter: {} }) looks like (note these are run directly against the replica set):

       

      {
              "cursor" : {
                      "id" : NumberLong(0),
                      "ns" : "test.repro",
                      "firstBatch" : [ ]
              },
              "ok" : 1
      }
      

      And once it's been added as a shard, it looks like

       

      {
              "cursor" : {
                      "id" : NumberLong(0),
                      "ns" : "test.repro",
                      "firstBatch" : [ ]
              },
              "ok" : 1,
              "operationTime" : Timestamp(1567098799, 3),
              "$gleStats" : {
                      "lastOpTime" : Timestamp(0, 0),
                      "electionId" : ObjectId("7fffffff0000000000000001")
              },
              "lastCommittedOpTime" : Timestamp(1567098799, 3),
              "$configServerState" : {
                      "opTime" : {
                              "ts" : Timestamp(1567098799, 6),
                              "t" : NumberLong(1)
                      }
              },
              "$clusterTime" : {
                      "clusterTime" : Timestamp(1567098799, 6),
                      "signature" : {
                              "hash" : BinData(0,"keF7J9EKgnmdyDc/6k4/R2wFh50="),
                              "keyId" : NumberLong("6730638087010910237")
                      }
              }
      }

       

      Additionally, after startup of a replica set with --keyFile but without --shardsvr, it appears there is also a short amount of time before which operationTIme and clusterTime are contained in responses.

      I've reproduced this on both 4.0.12 and 4.2.0. I've been unable to reproduce either case without --keyFile.

      These fields not being present can have downstream effects on clients which are using a ClientSession and rely on the operationTime or clusterTime being available in that ClientSession after issuing commands.

        Attachments

        1. reproduce.sh
          3 kB
          Kevin Rosendahl

          Activity

            People

            Assignee:
            ben.caimano Benjamin Caimano (Inactive)
            Reporter:
            kevin.rosendahl Kevin Rosendahl
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: