[SERVER-26399] Improve "Cannot select sync source behind our last applied optime" messages to include the optime in question Created: 29/Sep/16  Updated: 31/Oct/16  Resolved: 24/Oct/16

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

Type: Bug Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: William Schultz (Inactive)
Resolution: Done Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

When looking for a sync source, if we consider a node but decide not to use it because it is behind us, we log a message that looks like:

2016-09-14T15:31:11.564+0000 D REPL     [rsBackgroundSync] Cannot select sync source behind our last applied optime: WIN-K6DURTQEFVN:20017

This message would be more useful if it included the optime of the node and the node it is considering syncing from.



 Comments   
Comment by Githook User [ 24/Oct/16 ]

Author:

{u'username': u'will62794', u'name': u'William Schultz', u'email': u'will627@comcast.net'}

Message: SERVER-26399 Improved "Cannot select sync source" messages to include the relevant optimes
Branch: master
https://github.com/mongodb/mongo/commit/eae94d70dbb93fd69435c411e714e06944060975

Comment by Judah Schvimer [ 14/Oct/16 ]

This log message should also be corrected to say "Cannot select sync source that is equal to or behind our last applied optime". The line here is a less than or equal to operator, not a less than operator: https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/topology_coordinator_impl.cpp#L302 is:

if (it->getAppliedOpTime().getTimestamp() <= lastTimestampApplied) {

Comment by Judah Schvimer [ 30/Sep/16 ]

"Cannot select sync source because it is too far behind" should also include the relevant optimes.

Comment by Eric Milkie [ 30/Sep/16 ]

Actually, I've noticed that that new message, which was written based on the variable names in that function, is incorrect. The optime passed to the function is actually the last optime fetched, not applied. So we should change both the message and the variable name there.

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