Deploy a Self-Managed Replica Set (original) (raw)

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.

This page covers how to deploy a replica set for self-manageddeployments.

To learn more about deploying a replica set for deployments hosted in MongoDB Atlas, see Create a Cluster.

For production deployments, you should maintain as much separation between members as possible by hosting the mongodinstances on separate machines. When using virtual machines for production deployments, you should place each mongodinstance 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.

In production, deploy each member of the replica set to its own machine. If possible, ensure that MongoDB listens on the default port of27017.

Note

Outside of a rolling upgrade, all mongod members of a replica set should use the same major version of MongoDB.

For more information, see Replica Set Deployment Architectures.

Important

To avoid configuration updates due to IP address changes, use DNS hostnames instead of IP addresses. It is particularly important to use a DNS hostname instead of an IP address when configuring replica set members or sharded cluster members.

Use hostnames instead of IP addresses to configure clusters across a split network horizon. Starting in MongoDB 5.0, nodes that are only configured with an IP address fail startup validation and do not start.

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

Warning

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 localhost IPv6 address.

By default mongod and mongos that are bound to localhost only accept connections from clients that are running on the same computer. This binding behavior includesmongosh and other members of your replica set or sharded cluster. Remote clients cannot connect to binaries that are bound only to localhost.

To override the default binding and bind to other IP addresses, use thenet.bindIp configuration file setting or the --bind_ipcommand-line option to specify a list of hostnames or IP addresses.

Warning

For example, the following mongod instance binds to both the localhost and the hostname My-Example-Associated-Hostname, which is associated with the IP address 198.51.100.1:

mongod --bind_ip localhost,My-Example-Associated-Hostname

In order to connect to this instance, remote clients must specify the hostname or its associated IP address 198.51.100.1:

mongosh --host My-Example-Associated-Hostname

mongosh --host 198.51.100.1

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, seeTest 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.confor a related location.

For more information about configuration options, seeSelf-Managed Configuration File Options.

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

To deploy a replica set with enabled access control, seeDeploy Self-Managed Replica Set With Keyfile Authentication. If you wish to deploy a replica set from a single MongoDB instance, seeConvert a Standalone Self-Managed mongod to a Replica Set. For more information on replica set deployments, see the Replication andReplica Set Deployment Architectures documentation.

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 must have a distinct name.
• Set net.bindIp option to the hostname/ip or a comma-delimited list of hostnames/ips.
• Set any other settings as appropriate for your deployment.

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

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

Warning

mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>

For <hostname(s)|ip address(es)>, specify the hostname(s) and/or ip address(es) 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:

replication:

   replSetName: "rs0"

net:

   bindIp: localhost,<hostname(s)|ip address(es)>

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 scriptto manage this process. Init scripts are beyond the scope of this document.

From the same machine where one of the mongod is running (in this tutorial, mongodb0.example.net), startmongosh. To connect to the mongodlistening to localhost on the default port of 27017, simply issue:

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

If your mongod is not running on the default port, specify the--port option for mongosh.

From mongosh, run rs.initiate() on replica set member 0.

Important

Important

To avoid configuration updates due to IP address changes, use DNS hostnames instead of IP addresses. It is particularly important to use a DNS hostname instead of an IP address when configuring replica set members or sharded cluster members.

Use hostnames instead of IP addresses to configure clusters across a split network horizon. Starting in MongoDB 5.0, nodes that are only configured with an IP address fail startup validation and do not start.

rs.initiate( {

   _id : "rs0",

   members: [

      { _id: 0, host: "mongodb0.example.net:27017" },

      { _id: 1, host: "mongodb1.example.net:27017" },

      { _id: 2, host: "mongodb2.example.net:27017" }

   ]

})

MongoDB initiates a replica set, using the default 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" : "mongodb0.example.net:27017",

         "arbiterOnly" : false,

         "buildIndexes" : true,

         "hidden" : false,

         "priority" : 1,

         "tags" : {

         },

         "secondaryDelaySecs" : NumberLong(0),

         "votes" : 1

      },

      {

         "_id" : 1,

         "host" : "mongodb1.example.net:27017",

         "arbiterOnly" : false,

         "buildIndexes" : true,

         "hidden" : false,

         "priority" : 1,

         "tags" : {

         },

         "secondaryDelaySecs" : NumberLong(0),

         "votes" : 1

      },

      {

         "_id" : 2,

         "host" : "mongodb2.example.net:27017",

         "arbiterOnly" : false,

         "buildIndexes" : true,

         "hidden" : false,

         "priority" : 1,

         "tags" : {

         },

         "secondaryDelaySecs" : NumberLong(0),

         "votes" : 1

      }

         ],

   "settings" : {

      "chainingAllowed" : true,

      "heartbeatIntervalMillis" : 2000,

      "heartbeatTimeoutSecs" : 10,

      "electionTimeoutMillis" : 10000,

      "catchUpTimeoutMillis" : -1,

      "getLastErrorModes" : {

      },

      "getLastErrorDefaults" : {

         "w" : 1,

         "wtimeout" : 0

      },

      "replicaSetId" : ObjectId("585ab9df685f726db2c6a840")

   }

}

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

See also: