[SERVER-23630] Secondary with higher priority stepdown current primary. Created: 11/Apr/16  Updated: 06/Dec/22  Resolved: 15/Apr/16

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

Type: Bug Priority: Major - P3
Reporter: Zhang Youdong Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-22291 ReplicationCoordinatorImpl::_requestR... Closed
Related
is related to DOCS-7619 Add notes about how priorities affect... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Comments   
Comment by Scott Hernandez (Inactive) [ 11/Apr/16 ]

Yes, that is a bug. The command is sent with the wrong parameter(s). I believe we have an open issue to fix that. Thanks for pointing that out.

Comment by Zhang Youdong [ 11/Apr/16 ]

sorry for "submit" by mistake, I will describe the problem by comments because I cannot update the issue.

Affects Version: 3.2.3

The secondary with higher priority will send "{replSetStepDown: 1}" command to current primary.

src/mongo/db/repl/topology_coordinator_impl.cpp:1173

                } else if ((highestPriorityIndex == _selfIndex) && (_electionSleepUntil <= now)) {
                    // If this node is the highest priority node, and it is not in
                    // an inter-election sleep period, ask the current primary to step down.
                    // This is an optimization, because the remote primary will almost certainly
                    // notice this node's electability promptly, via its own heartbeat process.
                    log() << "Requesting that " << currentPrimaryMember.getHostAndPort()
                          << " (priority " << currentPrimaryMember.getPriority()
                          << ") step down because I have higher priority "
                          << highestPriorityMember.getPriority() << " and am only "
                          << (latestOpTime.getSecs() - highestPriorityMemberOptime.getSecs())
                          << " seconds behind it";
                    int primaryIndex = _currentPrimaryIndex;
                    _currentPrimaryIndex = -1;
                    return HeartbeatResponseAction::makeStepDownRemoteAction(primaryIndex);
                }

The primary received this command will execute the following code which return error the secondary, so the logic "secondary with higher priority stepdown primary" make nonsense.

src/mongo/db/repl/replset_commands.cpp:564

        if (stepDownForSecs < secondaryCatchUpPeriodSecs) {
            status = Status(ErrorCodes::BadValue,
                            "stepdown period must be longer than secondaryCatchUpPeriodSecs");
            return appendCommandStatus(result, status);
        }

Comment by Scott Hernandez (Inactive) [ 11/Apr/16 ]

The title is a little sparse so I'm going to attempt to guess at what you are seeing and believe is happening, but I may be a bit off so please help correct my assumptions if they are incorrect.

The point of higher priorities is to offer some control over which member is elected primary, so this sounds like expected behavior.

The docs cover this but could use some additional clean-up on the finer points: https://docs.mongodb.org/manual/core/replica-set-elections/#member-priority
https://docs.mongodb.org/manual/tutorial/adjust-replica-set-member-priority/

To be clear, a higher priority member may not only win an election (due to its priority) but also start an election, or have the primary step down, so it can have a chance to become primary.

If you are seeing something other than this, please upload steps to reproduce what you are seeing and logs/config showing the issue.

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