MongoDB Documentation, Release 3.0.4 STARTUP2 (page 655) until all data is copied and all indexes are built. Afterwards, the member transitions to RECOVERING (page 656). A member of a replica set enters RECOVERING (page 656) state when it is not ready to accept reads. The RECOVERING (page 656) state can occur during normal operation, and doesn’t necessarily reflect an error condition. Members in the RECOVERING (page 656) state are eligible to vote in elections, but are not eligible to enter the PRIMARY (page 655) state. A member transitions from RECOVERING (page 656) to SECONDARY (page 655) after replicating enough data to guarantee a consistent view of the data for client reads. The only difference between RECOVERING (page 656) and SECONDARY (page 655) states is that RECOVERING (page 656) prohibits client reads and SECONDARY (page 655) permits them. SECONDARY (page 655) 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 (page 633) with the rest of the set. When this happens, the member enters the RECOVERING (page 656) state and requires manual intervention. Error States Members in any error state can’t vote. Members that have never communicated status information to the replica set are in the UNKNOWN (page 656) state. Members that lose their connection to the replica set are seen as DOWN (page 656) by the remaining members of the set. Members that are removed from the replica set enter the REMOVED (page 656) state. When members enter the REMOVED (page 656) state, the logs will mark this event with a replSet REMOVED message entry. 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 (page 584), the member will have ROLLBACK (page 656) state. A member in FATAL (page 656) encountered an unrecoverable error. The member must be shut down and restarted; a resync may be required as well. By default, an application directs its read operations to the primary member in a replica set . Because write operations are issued to the single primary, reading from the primary returns the latest version of a document $^{25}$. Read preference describes how MongoDB clients route read operations to the members of a replica set . For an application that does not require fully up-to-date data, you can improve read throughput or reduce latency by distributing some or all reads to secondary members of the replica set. 25 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 (page 130). The node that can complete {w: majority} (page 130) 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 (page 657). Chapter 9. Replication 656 Read Preference Reference FATAL ROLLBACK REMOVED DOWN UNKNOWN RECOVERING