[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: 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. |