Check the status of your replica set at any time with the rs.status() operation. 

## See also: 

The documentation of the following shell functions for more information: 

• rs.initiate() 

• rs.conf() 

• rs.reconfig() 

• rs.add() 

You may also consider the simple setup script 19 as an example of a basic automatically-configured replica set. 

Refer to Replica Set Read and Write Semantics (page 585) for a detailed explanation of read and write semantics in MongoDB. 

## Deploy a Geographically Redundant Replica Set 

## Overview 

This tutorial outlines the process for deploying a replica set with members in multiple locations. The tutorial addresses three-member sets, four-member sets, and sets with more than four members. 

For appropriate background, see Replication (page 559) and Replica Set Deployment Architectures (page 572). For related tutorials, see Deploy a Replica Set (page 603) and Add Members to a Replica Set (page 616). 

## Considerations 

While replica sets provide basic protection against single-instance failure, replica sets whose members are all located in a single facility are susceptible to errors in that facility. Power outages, network interruptions, and natural disasters are all issues that can affect replica sets whose members are colocated. To protect against these classes of failures, deploy a replica set with one or more members in a geographically distinct facility or data center to provide redundancy. 

## Prerequisites 

In general, the requirements for any geographically redundant replica set are as follows: 

• Ensure that a majority of the voting members (page 583) are within a primary facility, “Site A”. This includes priority 0 members (page 567) and arbiters (page 571). Deploy other members in secondary facilities, “Site B”, “Site C”, etc., to provide additional copies of the data. See Determine the Distribution of Members (page 573) for more information on the voting requirements for geographically redundant replica sets. 

• If you deploy a replica set with an even number of members, deploy an arbiter (page 571) on Site A. The arbiter must be on site A to keep the majority there. 

For instance, for a three-member replica set you need two instances in a Site A, and one member in a secondary facility, Site B. Site A should be the same facility or very close to your primary application infrastructure (i.e. application servers, caching layer, users, etc.) 

A four-member replica set should have at least two members in Site A, with the remaining members in one or more secondary sites, as well as a single arbiter in Site A. 

