[SERVER-38754] Add optimizations for change streams using speculative majority Created: 21/Dec/18  Updated: 29/Oct/23  Resolved: 23/Jan/19

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

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
Related
related to SERVER-37560 Allow change streams to work with spe... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0, v3.6
Sprint: Repl 2019-01-14, Repl 2019-01-28
Participants:

 Description   

We want to add optimizations for change stream queries using speculative majority to reduce unnecessary waiting. These optimizations include waiting on the most recent scanned timestamp in an oplog batch as opposed to waiting on the most recent system-wide lastApplied optime. Such optimizations are only permissible if an updateLookup query is not being done locally on the node in addition to an oplog read.



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

Author:

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

Message: SERVER-38754 Make speculative majority change stream reads wait on optimized optimes

Speculative majority change stream oplog reads now only wait on the latest scanned oplog timestamp when possible, as opposed to always waiting on the latest system-wide lastApplied optime. If a document post-image lookup occurs locally for a change stream read, then this optimization is not safe, since the document lookup may reflect data at some unknown timestamp. In this case, we revert to waiting on the node's lastApplied optime.
Branch: master
https://github.com/mongodb/mongo/commit/ffb19c17927a5a0a07a7cd7cd7744cea80ab3e26

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