Details
-
Bug
-
Resolution: Won't Fix
-
Major - P3
-
None
-
None
-
None
-
None
-
ALL
-
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.