-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
ALL
-
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.