[SERVER-34121] "Cannot specify afterClusterTime readConcern without replication enabled" Created: 25/Mar/18  Updated: 27/Oct/23  Resolved: 26/Mar/18

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

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32531 Require --shardsvrs not started in qu... Closed
related to CDRIVER-2570 Test with replica set shards, not sta... Closed
Operating System: ALL
Participants:

 Description   

Starting a few days ago, C Driver tests against a sharded cluster with standalone (non-replica-set) shards fail. The test is attempting a listCollections command with causal consistency (readConcern afterClusterTime) on the mongos and receives "Cannot specify afterClusterTime readConcern without replication enabled".

Seems to be an unintended consequence of SERVER-33798. The driver sees that mongos includes $clusterTime and operationTime in its command responses and thinks that the deployment supports causal consistency. It obeys the Causal Consistency Spec:

When executing a causally consistent read, the afterClusterTime field MUST be sent when connected to a deployment that supports cluster times, and MUST NOT be sent when connected to a deployment that does not support cluster times.

I've only thought about this for a minute but I think the new error is a breaking change for 3.6-era drivers when they're configured for causal consistency. I propose relaxing the new check implemented in SERVER-33798: standalone shards shouldn't reject readConcern afterClusterTime, since standalones are naturally causally consistent. Alternatively, a mongos that knows of any standalone shards shouldn't advertise operationTime, but that's complicated and racy.



 Comments   
Comment by Ramon Fernandez Marina [ 26/Mar/18 ]

SERVER-32531 (Require --shardsvrs not started in queryable backup mode to be started as replica sets)

Comment by A. Jesse Jiryu Davis [ 26/Mar/18 ]

I guess this works as designed, thanks. I'll open a DRIVERS ticket to update our test deployments.

Comment by Andy Schwerin [ 26/Mar/18 ]

Standalone shards are not supported in 3.6 or later, per the release notes. We didn't remove the implementation, but we stopped testing it aggressively, and as of a few weeks ago, I think we've stopped testing it completely in the server tests.

I don't know if there's a ticket to refuse to start with --shardsvr is supplied without --replset, but janna.golden might.

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