MongoDB Replica Set: Set Up Three-Node HA Cluster (2026)

A MongoDB replica set isn’t just about keeping a copy of your data; it’s fundamentally about availability, meaning your application can keep writing even if one of your database servers dies.

Let’s see this in action. Imagine you have three MongoDB instances running, mongo1, mongo2, and mongo3. mongo1 is currently the primary, handling all writes.

# On mongo1:
rs.status()

You’ll see output like this, with stateStr: "PRIMARY" for mongo1 and stateStr: "SECONDARY" for mongo2 and mongo3.

{
  "set": "myReplicaSet",
  "members": [
    {
      "_id": 0,
      "name": "mongo1:27017",
      "stateStr": "PRIMARY",
      "health": 1
    },
    {
      "_id": 1,
      "name": "mongo2:27017",
      "stateStr": "SECONDARY",
      "health": 1
    },
    {
      "_id": 2,
      "name": "mongo3:27017",
      "stateStr": "SECONDARY",
      "health": 1
    }
  ],
  // ... other fields
}

Now, if mongo1 abruptly disappears (say, a power outage), the remaining secondaries (mongo2 and mongo3) will hold a quick election. Within seconds, one of them (let’s say mongo2) will be promoted to primary. Your application, if configured to connect to the replica set name, will automatically switch its writes to mongo2 without you lifting a finger.

# After mongo1 goes down, on mongo2:
rs.status()

You’ll see mongo2 is now the PRIMARY.

{
  "set": "myReplicaSet",
  "members": [
    {
      "_id": 0,
      "name": "mongo1:27017",
      "stateStr": "STARTUP2", // or other non-primary state
      "health": 0
    },
    {
      "_id": 1,
      "name": "mongo2:27017",
      "stateStr": "PRIMARY",
      "health": 1
    },
    {
      "_id": 2,
      "name": "mongo3:27017",
      "stateStr": "SECONDARY",
      "health": 1
    }
  ],
  // ... other fields
}

The core problem a replica set solves is single points of failure. Without it, if your single MongoDB server goes down, your application stops working. A replica set provides redundancy.

Internally, it works through a process called oplog replication. Every write operation on the primary is recorded in a special, capped collection called the oplog. The secondaries then tail this oplog and apply the same operations to their own data sets, ensuring they stay in sync. The election process is managed by the Raft consensus algorithm (or a variation of it), where nodes vote on who should become the new primary based on who has the most up-to-date oplog.

To set up a three-node replica set, you need to:

Configure each MongoDB instance: Each instance needs to be started with specific flags. For example, on mongo1:
```
mongod --replSet myReplicaSet --bind_ip localhost,<your_server_ip> --port 27017 --dbpath /data/db1 --logpath /data/log1.log --fork
```
Repeat this for mongo2 and mongo3, adjusting dbpath, logpath, and potentially port if they are on the same machine. Crucially, the --replSet myReplicaSet flag tells these instances to be part of a replica set named myReplicaSet. The --bind_ip is important for allowing other nodes to connect; use 0.0.0.0 for all interfaces if all nodes are on the same network and you’ve secured them with firewalls, or specific IPs for more control.
Initiate the replica set: Connect to any one of the running instances (e.g., mongo1) using the mongo shell and run the rs.initiate() command. This command takes a configuration document that lists all members of the replica set.
```
rs.initiate(
  {
    _id: "myReplicaSet",
    members: [
      { _id: 0, host: "mongo1.example.com:27017" },
      { _id: 1, host: "mongo2.example.com:27017" },
      { _id: 2, host: "mongo3.example.com:27017" }
    ]
  }
)
```
Replace mongo1.example.com, mongo2.example.com, and mongo3.example.com with the actual hostnames or IP addresses of your servers. The _id field for each member is an arbitrary integer that uniquely identifies that member within the set.
Verify the setup: After a few moments, run rs.status() on any member to confirm that all nodes are recognized and have a healthy state. You should see PRIMARY and SECONDARY states.

The most surprising thing about replica set elections is how robust they are to network partitions, but also how sensitive they are to the majority. A replica set needs a majority of its members available to elect a primary and to perform writes. For a three-node set, this means at least two nodes must be up. If you have an even number of nodes (e.g., 4), you need 3 to be up. This is why you often see deployments with an odd number of nodes, or an even number plus an arbiter (a lightweight process that participates in elections but doesn’t hold data).

The next logical step is to explore read preferences, which determine which members of the replica set your application queries will be sent to.