Replica set configuration basics in MongoDB

Introduction

A replica set keeps copies of your data on multiple servers. This helps your data stay safe and available even if one server stops working.

You want your database to keep working even if one server crashes.

You want to make sure your data is backed up automatically on other servers.

You want to read data from different servers to balance the load.

You want to upgrade or fix one server without stopping the whole database.

You want to protect your data from hardware failures.

Syntax

MongoDB

rs.initiate(configuration)

// configuration is an object that defines members and settings

The rs.initiate() command starts the replica set with your settings.

The configuration object includes a list of members (servers) with their IDs and addresses.

Examples

This simple command creates a replica set with just the current server as the only member.

MongoDB

rs.initiate()
// Starts a replica set with default settings and one member (the current server)

This command creates a replica set named rs0 with three members running on different ports.

MongoDB

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

Sample Program

This command sets up a replica set called myReplicaSet with two members on localhost ports 27017 and 27018.

MongoDB

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

Important Notes

Each member in the replica set must have a unique _id number starting from 0.

The host field must include the server address and port.

After initiating, use rs.status() to check the replica set health.

Summary

A replica set is a group of MongoDB servers that keep copies of the same data.

You configure it using rs.initiate() with a list of members.

This setup helps keep your data safe and your database available.

Practice

1. What is the main purpose of a MongoDB replica set?

easy

A. To keep multiple copies of data for safety and availability

B. To speed up queries by using multiple CPUs

C. To store data in different formats

D. To backup data to an external server

Solution

1. Step 1: Understand what a replica set is

   A replica set is a group of MongoDB servers that keep copies of the same data.

2. Step 2: Identify the main goal of this setup

   The main goal is to keep data safe and available by having multiple copies.

3. Final Answer:

   To keep multiple copies of data for safety and availability -> Option A

4. Quick Check:

   Replica set purpose = data safety and availability [OK]

Hint: Replica sets keep data copies for safety and uptime [OK]

Common Mistakes:

• Thinking replica sets speed up queries directly
• Confusing replica sets with backups
• Assuming replica sets change data formats

2. Which command correctly initiates a replica set with one member named 'mongo1'?

easy

A. rs.start({ _id: 'rs0', members: ['mongo1'] })

B. rs.initiate({ _id: 'rs0', members: [{ _id: 0, host: 'mongo1:27017' }] })

C. replicaSet.create({ name: 'rs0', nodes: ['mongo1'] })

D. initReplicaSet({ id: 'rs0', hosts: ['mongo1:27017'] })

Solution

1. Step 1: Recall the correct syntax for initiating a replica set

   The command is rs.initiate() with a config object including _id and members array.

2. Step 2: Check the options for correct syntax and fields

   rs.initiate({ _id: 'rs0', members: [{ _id: 0, host: 'mongo1:27017' }] }) uses rs.initiate with _id and members array with _id and host fields correctly.

3. Final Answer:

   rs.initiate({ _id: 'rs0', members: [{ _id: 0, host: 'mongo1:27017' }] }) -> Option B

4. Quick Check:

   rs.initiate with config object = correct syntax [OK]

Hint: Use rs.initiate with _id and members array for setup [OK]

Common Mistakes:

• Using wrong command names like rs.start or initReplicaSet
• Passing members as simple strings instead of objects
• Missing port number in host field

3. Given this replica set config:

rs.initiate({ _id: 'rs0', members: [ { _id: 0, host: 'mongo1:27017' }, { _id: 1, host: 'mongo2:27017' } ] })

What will be the state of the second member immediately after initiation?

medium

A. ARBITER

B. SECONDARY

C. PRIMARY

D. STARTUP

Solution

1. Step 1: Understand member states after rs.initiate()

   After initiation, members start in STARTUP state before election completes.

2. Step 2: Identify the initial state of the second member

   The second member will be in STARTUP state until it syncs and elections finish.

3. Final Answer:

   STARTUP -> Option D

4. Quick Check:

   New members start as STARTUP before becoming SECONDARY [OK]

Hint: New members start in STARTUP state before election [OK]

Common Mistakes:

• Assuming member is immediately PRIMARY or SECONDARY
• Confusing ARBITER with normal members
• Ignoring the startup phase after initiation

4. You run rs.initiate() but get an error: "members array is missing or empty." What is the likely cause?

medium

A. You did not provide a members array in the config object

B. You used the wrong command name

C. You included an invalid port number

D. You forgot to start the mongod service

Solution

1. Step 1: Analyze the error message

   The error says the members array is missing or empty, meaning the config lacks members.

2. Step 2: Match error to common causes

   Not providing the members array in rs.initiate config causes this error.

3. Final Answer:

   You did not provide a members array in the config object -> Option A

4. Quick Check:

   Missing members array = error message [OK]

Hint: Always include members array in rs.initiate config [OK]

Common Mistakes:

• Ignoring the need for members array
• Assuming wrong command name causes this error
• Thinking service not started causes this error

5. You want to add a third member as an arbiter to your replica set. Which configuration snippet correctly adds it?

hard

A. { _id: 2, host: 'mongo3:27017', votes: 0 }

B. { _id: 2, host: 'mongo3:27017', priority: 2 }

C. { _id: 2, host: 'mongo3:27017', arbiterOnly: true }

D. { _id: 2, host: 'mongo3:27017', hidden: true }

Solution

1. Step 1: Understand arbiter configuration

   An arbiter member is configured with the field arbiterOnly set to true.

2. Step 2: Identify the correct option

   { _id: 2, host: 'mongo3:27017', arbiterOnly: true } sets arbiterOnly: true, which correctly marks the member as an arbiter.

3. Final Answer:

   { _id: 2, host: 'mongo3:27017', arbiterOnly: true } -> Option C

4. Quick Check:

   ArbiterOnly true = arbiter member [OK]

Hint: Use arbiterOnly: true to add an arbiter member [OK]

Common Mistakes:

• Using priority or votes fields incorrectly for arbiters
• Confusing hidden members with arbiters
• Not setting arbiterOnly to true for arbiters