[SERVER-8085] Re-evaluate on how to compute for repl lag Created: 04/Jan/13  Updated: 04/Jan/13  Resolved: 04/Jan/13

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

Type: Task Priority: Major - P3
Reporter: Randolph Tan Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Participants:

 Description   

Before the batch oplog application was implemented, the secondary would record the oplog right away after applying one oplog operation. After the implementation was introduced in 2.2, mongod now records the oplog documents from the batch right after it finishes processing the entire batch. I believe this is done to preserve the same oplog ordering from the sync source. However, this widens the gap between the time that the operation has actually been applied on the secondary and the time the oplog entry is recorded in the secondary. The repl lag is currently calculated based on the timestamp difference between the latest oplog document, so it can display a lag value greater than the actual progress made by the secondary.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 04/Jan/13 ]

a batch has to be atomic, so this is correct behavior

Generated at Thu Feb 08 03:16:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.