[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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: 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. |
| Comment by Githook User [ 21/Dec/18 ] |
|
Author: {'username': 'will62794', 'email': 'william.schultz@mongodb.com', 'name': 'William Schultz'}Message: 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. |
| Comment by Githook User [ 21/Dec/18 ] |
|
Author: {'username': 'will62794', 'email': 'william.schultz@mongodb.com', 'name': 'William Schultz'}Message: 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. |
| Comment by Githook User [ 15/Nov/18 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: |
| Comment by Githook User [ 14/Nov/18 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: 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. |