-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
v5.1, v5.0, v4.4, v4.2
-
Repl 2021-10-18, Repl 2021-11-01
-
(copied to CRM)
Beginning in 4.2, MongoDB records the wall clock time at which the primary processes each operation with millisecond granularity and records the value in the oplog. Secondary nodes report these values back to the primary node when the issue replSetUpdatePosition, and the information is duly recorded in the TopologyCoordinator's data structure of member data.
If we went a step further and reported these values in the output of replSetGetStatus, it would be possible to calculate and report the primary's estimate of each secondary's replication lag in milliseconds. Presently, the optime is used to approximate this calculation, but it only has whole-second granularity, and due to monotonicity requirements can be incorrect for a long time after a clock adjustment on the primary node.
So, we should add, to each element of the members field returned in replSetGetStatus's response, that member's most recently reported last durable and last applied operation wall clock timestamps.
- related to
-
SERVER-40353 Add wall clock time corresponding to readConcernMajority OpTime to optimes subdocument
- Closed