[SERVER-35199] add sharding passthrough suite where config server secondaries have a significant slaveDelay Created: 23/May/18  Updated: 26/Oct/23

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

Type: Improvement Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea, pm-1377, shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Catalog and Routing
Participants:
Story Points: 3

 Description   

This will stress-test at least the following sharding logic:

  • readAfterOpTime of the configOpTime (which should be sent on all reads to config server nodes)
  • readConcern in metadata commands (reads can use the majority snapshot even if readConcern on opCtx is 'local' if a prior read, such as overtaking a distlock or loading the ShardRegistry, set the majority timestamp on the RecoveryUnit)
  • causal consistency of metadata changes (see SERVER-33954)

This could be a potential intern/new grad project - it's useful since it's test-only, but relatively low-risk.



 Comments   
Comment by Esha Maharishi (Inactive) [ 23/May/18 ]

Note that we'll have to allow setting a non-zero slaveDelay for --configsvrs, at least in test environments: https://github.com/mongodb/mongo/blob/r4.0.0-rc0/src/mongo/db/repl/repl_set_config.cpp#L580-L584.

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