-
Notifications
You must be signed in to change notification settings - Fork 15
REP-6832 Always read latest-possible version of documents #177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REP-6832 Always read latest-possible version of documents #177
Conversation
| // or for the last generation, the change stream end time. | ||
| cmd = append( | ||
| cmd, | ||
| bson.E{"readConcern", bson.D{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed on Slack in #go-driver channel, RunCommandCursor() will not use the read concern set on the MongoClient. Using read concern level "majority" must be set here explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. My takeaway from that thread was, “status quo is correct” … but it seems that that’s not actually the case.
| Int("count", len(docIDs)). | ||
| Any("latestTimestamp", latestTimestamp). | ||
| Time("latestTimestampTime", latestTimestampTime). | ||
| Stringer("lag", lag). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] What is the motivation for "lag" in the output here getting removed? I understand it is the only usage of changeEventBatch.clusterTime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s redundant with the lag that gets printed anyway in the logs’ periodic progress reports.
This improves the prevention of stale reads to incorporate the latest-seen cluster time and to use majority read concern.
This is particularly relevant when reading from secondaries, but it can also, because of SERVER-53813, affect reads from primaries.
This removes a
lagfrom a trace-level log in order to simplify things a bit. That data point is redundant with the periodically-reported lag in the logs anyway.