|
No problem; thanks for digging in to the source code!
|
|
@Eric Milkie
Thank you for your reply, I review the code logic and get your point, thank you very much.
|
|
Again, that code you have referenced does not involve electing primaries with "older oplogs". It does, however, provide some of the logic for implementing priority takeover in protocol version 0.
The logic for aborting elections of nodes that are not freshest is contained in the prepareFreshResponse() function, which is called before the code you are quoting above.
|
CmdReplSetElect::run()
|
getGlobalReplicationCoordinator()->processReplSetElect()
|
ReplicationCoordinatorImpl::_processReplSetElect_finish()
|
TopologyCoordinatorImpl::prepareElectResponse()
|
TopologyCoordinatorImpl::_getHighestPriorityElectableIndex()
|
TopologyCoordinatorImpl::_getUnelectableReason()
|
bool TopologyCoordinatorImpl::_isOpTimeCloseEnoughToLatestToElect(
|
const OpTime& otherOpTime, const OpTime& ourLastOpApplied) const {
|
const OpTime latestKnownOpTime = _latestKnownOpTime(ourLastOpApplied);
|
// Use addition instead of subtraction to avoid overflow.
|
return otherOpTime.getSecs() + 10 >= (latestKnownOpTime.getSecs());
|
}
|
|
|
Please note that the documentation and the code you referenced only apply to protocol version 0, which is not the default for new replica sets in version 3.2.
I believe the answer to your question is that your description of the function you have referenced is incorrect. That function is used for things like priority takeover qualification, but not for actually voting in a given election.
|
Generated at Thu Feb 08 04:04:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.