[SERVER-62008] Support majority read for $indexStats Created: 13/Dec/21  Updated: 21/May/23  Resolved: 02/Mar/22

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

Type: Task Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Benety Goh
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-64404 improve sharding support $listCatalog... Closed
is related to SERVER-62006 Support majority read for _mdb_catalog Closed
Sprint: Execution Team 2022-01-24, Execution Team 2022-02-21, Execution Team 2022-03-07
Participants:
Case:

 Description   

In C2C replication, we would like to only replicate majority committed data so that we can avoid handling rollbacks of the source cluster. This is now done by using majority readConcern in collection scans in the cloning phase. However, listDatabases/listCollections/listIndexes don't support reading majority committed catalog as the catalog is not versioned. This makes it very hard for an external process to detect when the result returned by these list commands rolls back. For mongosync, we are planning to use $indexStats instead of listIndexes to get the index info.

This work is to support read concern level “majority” for $indexStats (or support it for some new $listIndexes aggregation stage which targets all shards owning chunks) by reading from a majority committed snapshot of the _mdb_catalog without actually introducing versioned catalog.

And it should work for both replica sets and sharded clusters.



 Comments   
Comment by Benety Goh [ 02/Mar/22 ]

The indexStats aggregation stage reads the unversioned index usage tracker. The aggregation stage added in SERVER-62006 provides index specs from a snapshot of the _mdb_catalog that is consistent with the requested read concern.

Comment by Connie Chen [ 14/Dec/21 ]

lingzhi.deng could you provide more context on the motivation for this? 

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