[SERVER-58075] Consider forcing majority read concern for change streams shard monitor Created: 24/Jun/21  Updated: 27/Oct/23  Resolved: 16/Jul/21

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

Type: Bug Priority: Major - P3
Reporter: Justin Seyster Assignee: Bernard Gorman
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Sprint: Query Execution 2021-07-12, Query Execution 2021-07-26
Participants:

 Description   

The "shard monitor" cursor that each change stream opens on the config server replica set uses the read concern of the change stream:
https://github.com/mongodb/mongo/blob/493e0058075cb8ac67d1eda1cea94417ab11d30c/src/mongo/db/pipeline/sharded_agg_helpers.cpp#L116-L119

A majority read concern may be more appropriate, however, to ensure that the change stream never observes topology events that get rolled back.



 Comments   
Comment by Bernard Gorman [ 16/Jul/21 ]

After looking at this, I don't think we need to do anything here. We're opening a change stream on the config server, so even if we don't specify a readConcern or we inherit the current opCtx's readConcern, we will automatically upgrade the concern to majority on the remote.

Comment by Kyle Suarez [ 06/Jul/21 ]

bernard.gorman to find a new home for this ticket.

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