[SERVER-60746] Client sessions are not causally consistent for sharded metadata Created: 15/Oct/21  Updated: 26/Oct/23

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

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-61981 supporting_unique_index_check_is_vers... Closed
Assigned Teams:
Catalog and Routing
Sprint: Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27
Participants:
Linked BF Score: 0

 Description   

Gossiping the cluster time for causally consistent client sessions ensures causality for queries but it's not enough to ensure causality for sharded metadata operations.

Scenario:

  • One client communicating with 2 routers A and B
  • Router A performs shardCollection on db.coll
  • Router B receives a query forĀ db.coll, refreshes from the CSRS with nearest read preference and read concern with minimum last known config time
  • The CSRS secondary serving the refresh still didn't replicate the config.collections entry for db.coll
  • Router B treats db.coll as unsharded collection

At some point, router B will get to know that db.coll is sharded (e.g. after targeting the primary). However, gossiping the configOpTime and the topologyTime to the client would have allowed the second router to be causally consistent when refershing with afterClusterTime >= last known configOpTime.



 Comments   
Comment by Jordi Serra Torrens [ 29/Jun/23 ]

Removing from ShardRoleAPI since this is a Router role issue.

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