This version of the documentation is archived and no longer supported.

Deploy a Replica Set

This tutorial describes how to create a three-member replica set from three existing mongod instances running with access control disabled.

To deploy a replica set with enabled access control, see Deploy New Replica Set With Keyfile Access Control. If you wish to deploy a replica set from a single MongoDB instance, see Convert a Standalone to a Replica Set. For more information on replica set deployments, see the Replication and Replica Set Deployment Architectures documentation.


Three member replica sets provide enough redundancy to survive most network partitions and other system failures. These sets also have sufficient capacity for many distributed read operations. Replica sets should always have an odd number of members. This ensures that elections will proceed smoothly. For more about designing replica sets, see the Replication overview.


For production deployments, you should maintain as much separation between members as possible by hosting the mongod instances on separate machines. When using virtual machines for production deployments, you should place each mongod instance on a separate host server serviced by redundant power circuits and redundant network paths.

Before you can deploy a replica set, you must install MongoDB on each system that will be part of your replica set. If you have not already installed MongoDB, see the installation tutorials.

Considerations When Deploying a Replica Set


In production, deploy each member of the replica set to its own machine and if possible bind to the standard MongoDB port of 27017.

See Replica Set Deployment Architectures for more information.

IP Binding

Use the bind_ip option to ensure that MongoDB listens for connections from applications on configured addresses.

Changed in version 3.6: Starting in MongoDB 3.6, MongoDB binaries, mongod and mongos, bind to localhost ( by default. If the net.ipv6 configuration file setting or the --ipv6 command line option is set for the binary, the binary additionally binds to the IPv6 address ::1.

Previously, starting from MongoDB 2.6, only the binaries from the official MongoDB RPM (Red Hat, CentOS, Fedora Linux, and derivatives) and DEB (Debian, Ubuntu, and derivatives) packages bind to localhost by default.

When bound only to the localhost, these MongoDB 3.6 binaries can only accept connections from clients (including the mongo shell, other members in your deployment for replica sets and sharded clusters) that are running on the same machine. Remote clients cannot connect to the binaries bound only to localhost.

To override and bind to other ip addresses, you can use the net.bindIp configuration file setting or the --bind_ip command-line option to specify a list of ip addresses.


Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.

For example, the following mongod instance binds to both the localhost and the sample ip address

mongod --bind_ip localhost,

In order to connect to this instance, remote clients must specify the ip address or the hostname associated with the ip address:

mongo --host

mongo --host My-Example-Associated-Hostname


Ensure that network traffic can pass securely between all members of the set and all clients in the network .

Consider the following:

  • Establish a virtual private network. Ensure that your network topology routes all traffic between members within a single site over the local area network.
  • Configure access control to prevent connections from unknown clients to the replica set.
  • Configure networking and firewall rules so that incoming and outgoing packets are permitted only on the default MongoDB port and only from within your deployment. See the IP Binding considerations.

Ensure that each member of a replica set is accessible by way of resolvable DNS or hostnames. You should either configure your DNS names appropriately or set up your systems’ /etc/hosts file to reflect this configuration.

Each member must be able to connect to every other member. For instructions on how to check your connection, see Test Connections Between all Members.


Create the directory where MongoDB stores data files before deploying MongoDB.

Specify the mongod configuration in a configuration file stored in /etc/mongod.conf or a related location.

For more information about configuration options, see Configuration File Options.


The following procedure outlines the steps to deploy a replica set when access control is disabled.


Start each member of the replica set with the appropriate options.

For each member, start a mongod instance with the following settings:

  • Set replication.replSetName option to the replica set name,

    If your application connects to more than one replica set, each set should have a distinct name. Some drivers group replica set connections by replica set name.

  • Set net.bindIp option to the ip or a comma-delimited list of ips, and

  • Set any other settings as appropriate for your deployment.

In this tutorial, the three mongod instances are associated with the following hosts:

Replica Set Member Hostname
Member 0
Member 1
Member 2

The following example specifies the replica set name and the ip binding through the --replSet and --bind_ip command-line options:


Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.

mongod --replSet "rs0" --bind_ip localhost,<ip address of the mongod host>

For <ip address>, specify the ip address or hostname for your mongod instance that remote clients (including the other members of the replica set) can use to connect to the instance.

Alternatively, you can also specify the replica set name and the ip addresses in a configuration file:

   replSetName: "rs0"
   bindIp: localhost,<ip address>

To start mongod with a configuration file, specify the configuration file’s path with the --config option:

mongod --config <path-to-config>

In production deployments, you can configure a init script to manage this process. Init scripts are beyond the scope of this document.


Connect a mongo shell to one of the mongod instances.

From the same machine where one of the mongod is running (in this tutorial,, start the mongo shell. To connect to the mongod listening to localhost on the default port of 27017, simply issue:


Depending on your path, you may need to specify the path to the mongo binary.


Initiate the replica set.

From the mongo shell, run rs.initiate() on replica set member 0.


Run rs.initiate() on just one and only one mongod instance for the replica set.

rs.initiate( {
   _id : "rs0",
   members: [
      { _id: 0, host: "" },
      { _id: 1, host: "" },
      { _id: 2, host: "" }

MongoDB initiates a replica set, using the default replica set configuration.


View the replica set configuration.

Use rs.conf() to display the replica set configuration object:


The replica set configuration object resembles the following:

   "_id" : "rs0",
   "version" : 1,
   "protocolVersion" : NumberLong(1),
   "members" : [
         "_id" : 0,
         "host" : "",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

         "slaveDelay" : NumberLong(0),
         "votes" : 1
         "_id" : 1,
         "host" : "",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

         "slaveDelay" : NumberLong(0),
         "votes" : 1
         "_id" : 2,
         "host" : "",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {

         "slaveDelay" : NumberLong(0),
         "votes" : 1

   "settings" : {
      "chainingAllowed" : true,
      "heartbeatIntervalMillis" : 2000,
      "heartbeatTimeoutSecs" : 10,
      "electionTimeoutMillis" : 10000,
      "catchUpTimeoutMillis" : -1,
      "getLastErrorModes" : {

      "getLastErrorDefaults" : {
         "w" : 1,
         "wtimeout" : 0
      "replicaSetId" : ObjectId("585ab9df685f726db2c6a840")

Ensure that the replica set has a primary.

Use rs.status() to identify the primary in the replica set.