Replica Set Member States¶
Each member of a replica set has a state.
The member in state primary is the only member that can accept write operations. Eligible to vote.
A member in state secondary is replicating the data store. Eligible to vote.
The member has joined the set and is running an initial sync. Eligible to vote.
The member's state, as seen from another member of the set, is not yet known.
Arbiters do not replicate data and exist solely to participate in elections. Eligible to vote.
The member, as seen from another member of the set, is unreachable.
This member was once in a replica set but was subsequently removed.
PRIMARYstate accept write operations. A replica set has at most one primary at a time.  A
SECONDARYmember becomes primary after an election. Members in the
PRIMARYstate are eligible to vote.
SECONDARYstate replicate the primary's data set and can be configured to accept read operations. Secondaries are eligible to vote in elections, and may be elected to the
PRIMARYstate if the primary becomes unavailable.
ARBITERstate do not replicate data or accept write operations. They are eligible to vote, and exist solely to break a tie during elections. Replica sets should only have a member in the
ARBITERstate if the set would otherwise have an even number of voting members, and could suffer from tied elections. There should only be at most one arbiter configured in any replica set. For considerations when using an arbiter, see Replica Set Arbiter.
See Replica Set Members for more information on core states.
Each member of a replica set starts up in
mongodthen loads that member's replica set configuration, and transitions the member's state to
ARBITER. Members in
STARTUPare not eligible to vote, as they are not yet a recognized member of any replica set.
Each data-bearing member of a replica set enters the
STARTUP2state as soon as
mongodfinishes loading that member's configuration, at which time it becomes an active member of the replica set and is eligible to vote. The member then decides whether or not to undertake an initial sync. If a member begins an initial sync, the member remains in
STARTUP2until all data is copied and all indexes are built. Afterwards, the member transitions to
A member of a replica set enters
RECOVERINGstate when it is not ready to accept reads. The
RECOVERINGstate can occur during normal operation, and doesn't necessarily reflect an error condition. Members in the
RECOVERINGstate are eligible to vote in elections, but are not eligible to enter the
A member transitions from
SECONDARYafter replicating enough data to guarantee a consistent view of the data for client reads. The only difference between
SECONDARYstates is that
RECOVERINGprohibits client reads and
SECONDARYstate does not guarantee anything about the staleness of the data with respect to the primary.
Due to overload, a secondary may fall far enough behind the other members of the replica set such that it may need to resync with the rest of the set. When this happens, the member enters the
RECOVERINGstate and requires manual intervention.
Whenever the replica set replaces a primary in an election, the old primary may contain documents that did not replicate to the secondary members. In this case, the old primary member reverts those writes. During rollback, the member will have
ROLLBACKstate. Members in the
ROLLBACKstate are eligible to vote in elections.
Starting in version 4.2, MongoDB kills all in-progress user operations when a member enters the
Members in any error state can't vote.
Members that have never communicated status information to the replica set are in the
Members that lose their connection to the replica set are seen as
DOWNby the remaining members of the set.
||| In some circumstances, two nodes in a replica set
may transiently believe that they are the primary, but at most, one
of them will be able to complete writes with |