[SERVER-34964] KeysCollectionManager does not refresh immediately on 3.6 shard startup when added to a sharded claster Created: 11/May/18  Updated: 12/Dec/23

Status: Backlog
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.4
Fix Version/s: 4.1 Desired

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: sharding-causes-bfs-hard, sharding-wfbf-sprint
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Cluster Scalability
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

The issue is observable only in v3.6 the BACKPORT-1861 made the absence of keys apparent as the clusterTime was removed from the metadata (before there was a dummy signature)

The problem happens in an ReplicaSet started with shardsvr:true and later added to a sharded cluster or in a ShardingTest with auth

The KeysCollectionManager starts the monitoring thread when the RS is aded to a cluster and does not make initial refresh but eventually refreshing within 30 seconds (default refresh interval)



 Comments   
Comment by Misha Tyulenev [ 31/May/18 ]

This line is a workaround https://github.com/mongodb/mongo/blob/r3.6.5/jstests/sharding/mongod_returns_no_cluster_time_without_keys.js#L46
So repro the issue need just remove the highlighted line.

Comment by Kaloian Manassiev [ 11/May/18 ]

misha.tyulenev, can you update the description of this ticket a bit with what is the problem/how does it manifest itself (perhaps repro steps) so that someone who doesn't have that context can pick it up?

Generated at Thu Feb 08 04:38:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.