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