Question: How can you configure a MongoDB replica set without an arbiter?

Answer

A MongoDB replica set is a group of mongod instances that maintain the same data set. Replica sets provide redundancy and high availability, and are the basis for all production deployments. While most discussions around replica sets focus on having an odd number of members to avoid split-brain scenarios (where two parts of a distributed system cannot agree on the state of the system), it's entirely possible and sometimes desirable to configure a replica set without an arbiter.

Why Avoid Arbiters?

Arbiters participate in elections to help choose a new primary when necessary but do not hold data. They are often used to achieve an odd number of votes in the replica set without adding additional data-bearing nodes. However, arbiters can introduce issues:

• Network Dependency: Arbiters need to be reachable for elections, making your replica set more sensitive to network partitions.
• Resource Utilization: Although they don't store data, arbiters still consume resources and require maintenance.

Configuring Without an Arbiter

To maintain high availability without an arbiter, ensure you have an odd number of data-bearing nodes. This could mean running three, five, or more nodes that store data and participate in elections.

Here’s a simple example on how to set up a three-node replica set without an arbiter:

1. Initialize the Replica Set: Start each MongoDB instance with the replSet option.

   mongod --port 27017 --dbpath /srv/mongodb/rs0-0 --replSet rs0
   mongod --port 27018 --dbpath /srv/mongodb/rs0-1 --replSet rs0
   mongod --port 27019 --dbpath /srv/mongodb/rs0-2 --replSet rs0

2. Connect to One Node: Use the mongo shell to connect to one of the nodes.

   mongo --port 27017

3. Initiate the Replica Set: Use the rs.initiate() method with a configuration object specifying the _id, members, and their roles.

   rs.initiate({
     _id: "rs0",
     members: [
       { _id: 0, host: "localhost:27017" },
       { _id: 1, host: "localhost:27018" },
       { _id: 2, host: "localhost:27019" }
     ]
   })

This configuration creates a replica set with three data-bearing nodes, avoiding the use of an arbiter. All three nodes can vote in elections and serve read queries, enhancing the durability and availability of your database.

Best Practices

• Monitor your replica set: Ensure you have monitoring in place to quickly identify and resolve any issues with node availability or performance.
• Regularly test failover: Simulate failures to ensure your application can correctly handle a primary node election and continue operation seamlessly.
• Consider your workload: Write-heavy workloads might benefit from more nodes to distribute write operations, while read-heavy workloads might prioritize more secondary nodes for read scaling.

By carefully considering the architecture of your MongoDB replica set, you can achieve high availability and durability without relying on arbiters.