[SERVER-34598] Add millisecond-granularity wallclock times for the various metrics in replSetGetStatus's optimes subdocument Created: 20/Apr/18  Updated: 20/Jul/20  Resolved: 30/Apr/19

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

Type: Improvement Priority: Major - P3
Reporter: Andy Schwerin Assignee: Maria van Keulen
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-40078 Add wall clock time corresponding to ... Closed
depends on SERVER-40080 Add lastApplied and lastDurable wall ... Closed
depends on SERVER-40353 Add wall clock time corresponding to ... Closed
is depended on by SERVER-39494 Clean up chosen Flow Control POC Closed
Documented
is documented by DOCS-12667 Document newly-added wall clock times... Closed
Related
related to SERVER-40683 Make wall clock times in replication ... Closed
is related to SERVER-49732 Change _currentCommittedSnapshot to b... Closed
Backport Requested:
v4.0, v3.6
Sprint: Repl 2018-11-05, Storage NYC 2019-02-25, Storage NYC 2019-03-11
Participants:
Story Points: 5

 Description   

The response to replSetGetStatus includes a subdocument named optimes, which contains the OpTime for various important oplog events, including lastCommittedOpTime, readConcernMajorityOpTime, appliedOpTime and durableOpTime. As of MongoDB 3.6, the actual oplog entries corresponding to these OpTimes have a wall clock time with milliseconds resolution recorded in them. We should extend replSetGetStatus to report the wall clock times corresponding to these optimes, so that we can (usually) get millisecond-granularity measurements of replication lag and back-to-back majority read-modify-write latencies.

The work for this ticket is split into SERVER-40080, SERVER-40078, and SERVER-40353. SERVER-34598 is an umbrella ticket with no work items.



 Comments   
Comment by Maria van Keulen [ 30/Apr/19 ]

Closing this umbrella ticket, as all of its constituent tickets have been resolved.

Comment by Maria van Keulen [ 19/Mar/19 ]

This ticket is being actively worked on. However, since it is an umbrella ticket and not a real work ticket, I am moving this to the Backlog so it can be closed when SERVER-40080 and SERVER-40078 are complete.

Comment by Maria van Keulen [ 11/Mar/19 ]

Since this ticket is a feature-requesting ticket, I will use it as an umbrella ticket for the work tickets SERVER-40080 and SERVER-40078.

Comment by Maria van Keulen [ 11/Mar/19 ]

This ticket will now just track the work for adding the wall clock times corresponding to the lastApplied and lastDurable optimes to replSetGetStatus, given the complexity of these changes thus far. SERVER-40078 will handle the remaining two optimes.

Comment by Andy Schwerin [ 29/Jan/19 ]

Yes. I need it for planning.

Comment by Eric Milkie [ 29/Jan/19 ]

It is still scheduled for 4.2 for us to complete, but we may not end up needed it for this project.  Is there dependent work from DS that requires it?

Comment by Andy Schwerin [ 29/Jan/19 ]

Is this still happening in 4.2?

---------- Forwarded message ---------
From: Sara Williamson (Jira) <jira@mongodb.org>
Date: Mon, Jan 28, 2019, 4:10 PM
Subject: [MongoDB-JIRA] (SERVER-34598) Add millisecond-granularity
wallclock times for the various metrics in replSetGetStatus's optimes
subdocument
To: <schwerin@mongodb.com>

[
https://jira.mongodb.org/browse/SERVER-34598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sara Williamson updated SERVER-34598:
-------------------------------------
Story Points: 5

replSetGetStatus's optimes subdocument
-------------------------------------------------------------------------------------------------------------
optimes, which contains the OpTime for various important oplog events,
including lastAppliedOpTime, readConcernMajorityOpTime,
appliedOpTime and durableOpTime. As of MongoDB 3.6, the actual
oplog entries corresponding to these OpTimes have a wall clock time with
milliseconds resolution recorded in them. We should extend
replSetGetStatus to report the wall clock times corresponding to these
optimes, so that we can (usually) get millisecond-granularity measurements
of replication lag and back-to-back majority read-modify-write latencies.

----------------------
This message was sent from MongoDB's issue tracking system. To respond to
this ticket, please login to https://jira.mongodb.org using your JIRA or
MMS credentials.

Comment by Maria van Keulen [ 03/Dec/18 ]

The work for this ticket should include correctness testing to ensure the wall clock times are the values they are expected to be.

Comment by Andy Schwerin [ 23/Apr/18 ]

Don't need it for other nodes.

Comment by Spencer Brody (Inactive) [ 20/Apr/18 ]

To have this information for other nodes would require transmitting it via heartbeats and/or the replication spanning tree.

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