Replica Set Member States
Each member of a replica set has a state.
Number | Name | State Description |
---|---|---|
0 | Not yet an active member of any set. All members start up in
this state. The mongod parses the replica set
configuration document while in
STARTUP . | |
1 | The member in state primary
is the only member that can accept write operations. Eligible to
vote. | |
2 | A member in state secondary
is replicating the data store. Eligible to vote. | |
3 | ||
5 | The member has joined the set and is running an initial sync. Eligible to
vote. | |
6 | The member's state, as seen from another member of the set, is not yet known. | |
7 | Arbiters do not replicate data and exist solely to participate in elections. Eligible to vote. | |
8 | The member, as seen from another member of the set, is unreachable. | |
9 | ||
10 | This member was once in a replica set but was subsequently removed. |
States
Core States
PRIMARY
Members in
PRIMARY
state accept write operations. A replica set has at most one primary at a time. [1] ASECONDARY
member becomes primary after an election. Members in thePRIMARY
state are eligible to vote.
SECONDARY
Members in
SECONDARY
state 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 thePRIMARY
state if the primary becomes unavailable.
ARBITER
Members in
ARBITER
state 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 theARBITER
state 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.
Other States
STARTUP
Each member of a replica set starts up in
STARTUP
state.mongod
then loads that member's replica set configuration, and transitions the member's state toSTARTUP2
orARBITER
. Members inSTARTUP
are not eligible to vote, as they are not yet a recognized member of any replica set.
STARTUP2
Each data-bearing member of a replica set enters the
STARTUP2
state as soon asmongod
finishes 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 inSTARTUP2
until all data is copied and all indexes are built. Afterwards, the member transitions toRECOVERING
.
RECOVERING
A member of a replica set enters
RECOVERING
state when it is not ready to accept reads. TheRECOVERING
state can occur during normal operation, and doesn't necessarily reflect an error condition. Members in theRECOVERING
state are eligible to vote in elections, but are not eligible to enter thePRIMARY
state.A member transitions from
RECOVERING
toSECONDARY
after replicating enough data to guarantee a consistent view of the data for client reads. The only difference betweenRECOVERING
andSECONDARY
states is thatRECOVERING
prohibits client reads andSECONDARY
permits them.SECONDARY
state 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
RECOVERING
state and requires manual intervention.
ROLLBACK
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
ROLLBACK
state. Members in theROLLBACK
state are eligible to vote in elections.Starting in version 4.2, MongoDB kills all in-progress user operations when a member enters the
ROLLBACK
state.
Error States
Members in any error state can't vote.
UNKNOWN
Members that have never communicated status information to the replica set are in the
UNKNOWN
state.
DOWN
Members that lose their connection to the replica set are seen as
DOWN
by the remaining members of the set.
REMOVED
Members that are removed from the replica set enter the
REMOVED
state. When members enter theREMOVED
state, the logs will mark this event with areplSet REMOVED
message entry.
[1] | 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 { w:
"majority" } write concern. The node that can complete
{ w: "majority" } writes is the current
primary, and the other node is a former primary that has not yet
recognized its demotion, typically due to a network partition.
When this occurs, clients that connect to the former primary may
observe stale data despite having requested read preference
primary , and new writes to the former primary will
eventually roll back. |