[SERVER-49895] Expose getLatestOplogTimestamp() in aggregation cursor command responses on oplog Created: 25/Jul/20 Updated: 29/Oct/23 Resolved: 28/Aug/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Alexander Taskov (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M2, PM-234-T-oplog-fetch, query-work-resharding | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Sharding 2020-09-07 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
| Comments |
| Comment by Githook User [ 28/Aug/20 ] | |||
|
Author: {'name': 'Alex Taskov', 'email': 'alex.taskov@mongodb.com', 'username': 'alextaskov'}Message: | |||
| Comment by Max Hirschhorn [ 27/Jul/20 ] | |||
CollectionScan invariants that CollectionScanParams::shouldTrackLatestOplogTimestamp can only be set to true for an oplog namespace. We'll need to turn that into a uassert() as part of this ticket to add user-facing syntax to enable it.
| |||
| Comment by Daniel Gottlieb (Inactive) [ 27/Jul/20 ] | |||
That's valuable reasoning, thanks for adding that.
Ok good, glad we're on the same page there.
I didn't mean the second-order interpretation of "standalone", but rather the natural "node that does not have a real oplog". I was trying to understand why internal code querying for the latest oplog timestamp when it doesn't exist shouldn't be considered an error. My interpretation now is that it's fine for the lower level API to return an error (for example, when the oplog doesn't exist, or when the document found does not include a ts field) – but the expected reason the response building code would observe LatestOplogTimestamp.isNull() is simply "TRACK_LATEST_OPLOG_TS" was not set (or if the query wasn't for the oplog? not sure if that's an expected case, or a scenario of a misbehaving client). | |||
| Comment by Max Hirschhorn [ 27/Jul/20 ] | |||
|
A null timestamp won't ever be recorded in the oplog so I don't see how it could ever be an expected state. CollectionScan::getLatestOplogTimestamp(), PlanExecutor::getLatestOplogTimestamp(), etc. return a Timestamp and not a boost::optional<Timestamp>.
The reason why I said to omit the field from the cursor response when latestOplogTimestamp.isNull() is because the find, aggregate, and getMore commands need not bother to check if they are an oplog cursor. latestOplogTimestamp being a non-null Timestamp should automatically imply that.
I don't see a reason a replica set member started as a standalone couldn't make use of this feature. | |||
| Comment by Daniel Gottlieb (Inactive) [ 27/Jul/20 ] | |||
Is that preemptively defensive (e.g: instead of uasserting on standalones)? Or would seeing a null timestamp imply an expected state? |