[SERVER-34825] Oplog fetcher on shard servers can send afterClusterTime reads without gossiping $clusterTime Created: 03/May/18  Updated: 12/Dec/23

Status: Backlog
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: max-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Cluster Scalability
Operating System: ALL
Participants:

 Description   

The oplog fetcher always appends afterClusterTime to the find commands it runs against the primary in a replica set. The task executor it uses does have the LogicalTimeMetadataHook attached, but the hook only attaches $clusterTime to requests if the LogicalTimeValidator is set, which it won't be before a shard server has initialized its sharding state. This allows afterClusterTime reads to be sent without $clusterTime, which I don't think is normally allowed (at least for clients).

This may not be such a problem in practice though, because this is only before sharding initialization, and the fetcher only sends requests to the primary, using an afterClusterTime based off the opTimes it has already fetched, which I believe the primary should always have.

If we decide to change this but still need to send afterClusterTime in every fetcher's find, we may be able to change the LogicalTimeMetadata hook to always send $clusterTime even when the validator isn't enabled, since we don't authenticate times for __system connections anyway, like those between replica set members.



 Comments   
Comment by Kaloian Manassiev [ 11/May/18 ]

Fixing this allows us to introduce more invariants around cluster time so it would be good to do. Jack proposed a solution to always send the cluster time even if there is no validator, so we should explore that.

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