[SERVER-37560] Allow change streams to work with speculative majority reads Created: 10/Oct/18  Updated: 29/Oct/23  Resolved: 21/Dec/18

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

Type: Task Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-38218 AutoGetCollection doesn't need to cal... Closed
depends on SERVER-37935 Remove read concern "majority" overri... Closed
is depended on by SERVER-37221 Enable change streams with enableMajo... Closed
Documented
is documented by DOCS-12334 Docs for SERVER-37560: Allow change s... Closed
Related
related to SERVER-57197 [ephemeralForTest] improve error mess... Closed
related to SERVER-37178 [POC] Allow change streams to work wi... Closed
is related to SERVER-34277 Add 'maxAwaitTimeMs' parameter to get... Backlog
is related to SERVER-38727 Add command parameter to specify max ... Closed
is related to SERVER-38754 Add optimizations for change streams ... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0, v3.6
Sprint: Repl 2018-11-05, Repl 2018-11-19, Repl 2018-12-03, Repl 2018-12-17, Repl 2019-01-14
Participants:

 Description   

Allow change streams to work with the speculative majority reads implementation, so that they can work correctly even without storage engine support for majority reads enabled.



 Comments   
Comment by Githook User [ 23/Jan/19 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-37560 Enforce monotonicity of speculative read optimes automatically and rename setSpeculativeReadOpTime

Allow clients to set speculative read optimes on SpeculativeMajorityReadInfo in an order that is not monotonically increasing. Instead, when a new optime is reported, we only update the current speculative read optime if it is less than the new optime. This makes it easier for clients to utilize this class in the cases where they may not know what other clients are setting read optimes and when they do so in the course of a command execution.
Branch: master
https://github.com/mongodb/mongo/commit/36e9a68390989b87718b8df3a7d419ba870f9692

Comment by Githook User [ 21/Dec/18 ]

Author:

{'username': 'will62794', 'email': 'william.schultz@mongodb.com', 'name': 'William Schultz'}

Message: SERVER-37560 Allow change streams to work with speculative majority reads

This patch allows change stream queries to use speculative majority reads so that they can be used even when enableMajorityReadConcern:false. Change stream aggregation commands are allowed to use speculative majority reads as well as 'find' commands that specify a special flag. This commit also enables all change streams tests and suites on the enableMajorityReadConcern:false Evergreen variant. No optimizations for speculative majority change streams are included in this commit.
Branch: master
https://github.com/mongodb/mongo/commit/435200964a1fc9de566e74bd579e99c308551670

Comment by Githook User [ 21/Dec/18 ]

Author:

{'username': 'will62794', 'email': 'william.schultz@mongodb.com', 'name': 'William Schultz'}

Message: SERVER-37560 Add core functionality for speculative majority reads

This patch adds functionality for "speculative" majority reads. These are reads that can satisfy "majority" read concern guarantees without support from the storage engine for reading from a historical snapshot. Queries of this nature will, by default, wait on the most recent lastApplied optime to majority commit after they complete, but before returning to the client. They can also optionally set a custom optime T to wait on, if they know that they did not read any data that reflects the effects of operations newer than optime T.
Branch: master
https://github.com/mongodb/mongo/commit/f15556ae1ba4f78d2823d54e38d7025c7e9ca4fb

Comment by Githook User [ 15/Nov/18 ]

Author:

{'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}

Message: SERVER-37560 Store ReadConcernArgs on cursor object instead of ReadConcernLevel
Branch: master
https://github.com/mongodb/mongo/commit/72789f5739982af1cbdb1dd4fa181c4924f657b3

Comment by Githook User [ 14/Nov/18 ]

Author:

{'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}

Message: SERVER-37560 Add API for allowing commands to support speculative majority reads

This patch lays the groundwork for allowing read queries to take advantage of "speculative" majority reads, which is a mechanism for satisfying majority read guarantees without storage engine support for reading from a historical snapshot. This patch adds a flag on the ReadConcernArgs object to indicate whether a query should use the speculative behavior, and it also adds a method to the CommandInvocation interface that allows commands to optionally support speculative majority reads. The intention is to initially only utilize this behavior for change stream queries i.e. 'aggregate' and 'find' commands, but the feature is, in theory, generic.
Branch: master
https://github.com/mongodb/mongo/commit/a6a0ca1ae81b34aab14a9c9a2a3d4a6ec7be66ba

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