[SERVER-9728] Is there any specific way (calculation) to check replication lag. Created: 20/May/13 Updated: 10/Dec/14 Resolved: 20/May/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Manish | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
Hi, I have found in MongoDB documentation that "An ISODate formatted date string that reflects the last entry from the oplog that this member applied. If this differs significantly from lastHeartbeat this member is either experiencing “replication lag” or there have not been any new operations since the last update" My question is,Is there any particular calculation or some thing else through which I can measure replication lag. Below is the statics on basis of that I want to check any Replication Lag. "members" : [ "health" : 1, , }, , , } Thanks |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 02/Sep/13 ] | ||||
|
printSlaveReplicationInfo() is comparing the optimes of the secondary to the primary, not current time. The output of the command is confusing, which is why it was changed to be more clear with this ticket: Output now looks like this:
| ||||
| Comment by Sumeet Sharma [ 30/Aug/13 ] | ||||
|
The printSlaveReplicationInfo() represents how far behind the secondaries are from the *currentTime*. This is slightly misleading coz if there is no operation, rs.status().members.optimeDate doesnot update. Causing the optimeDate - now() to reflect a large number even though slaves are not out of date from primary. Wrote a function to compare the primary(as Eliot mentioned): function getReplicationLag() { else {secondary[a.name]=a.optimeDate;}} ); } | ||||
| Comment by Eliot Horowitz (Inactive) [ 20/May/13 ] | ||||
|
You just need to compare the optime on a secondary to the primary. So if you look at the optimes above, you'll see that the are the same for all nodes, so there is no lag. |