Replica set configuration basics in MongoDB - Step-by-Step Execution

Concept Flow - Replica set configuration basics

Start Replica Set

↓

Define Members

↓

Set Configuration Object

↓

Apply Configuration

↓

Replica Set Initiated

↓

Members Sync Data

↓

Replica Set Running

This flow shows how a MongoDB replica set is configured step-by-step, from defining members to running the set.

Execution Sample

MongoDB

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

This command initializes a replica set named 'rs0' with two members running on localhost ports 27017 and 27018.

Execution Table

Step	Action	Configuration State	Result
1	Call rs.initiate()	No replica set configured	Start configuration process
2	Define _id and members	{"_id":"rs0","members":[{"_id":0,"host":"localhost:27017"},{"_id":1,"host":"localhost:27018"}]}	Configuration object created
3	Apply configuration to replica set	Replica set config applied	Replica set initiated
4	Members start syncing data	Members syncing	Data replication begins
5	Replica set running	Replica set active	Primary and secondary members operational
6	Check rs.status()	Replica set active with members	Shows current state of members
7	Exit	Replica set running	Configuration complete and stable

💡 Replica set is running with defined members and data replication active

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
_id	undefined	"rs0"	"rs0"	"rs0"	"rs0"
members	undefined	[{_id:0,host}, {_id:1,host}]	[{_id:0,host}, {_id:1,host}]	[{_id:0,host}, {_id:1,host}]	[{_id:0,host}, {_id:1,host}]
replicaSetState	none	config object created	initiated	running	running

Key Moments - 3 Insights

Why do we need to assign unique _id values to each member?

Each member must have a unique _id to identify it within the replica set configuration, as shown in step 2 of the execution_table.

What happens if we call rs.initiate() without a configuration object?

MongoDB creates a default configuration with the current mongod as the only member, but explicit configuration (step 2) is recommended for multiple members.

How do members know to start syncing data?

After the configuration is applied (step 3), members automatically begin syncing data to maintain replication (step 4).

Visual Quiz - 3 Questions

Look at the execution_table, what is the configuration state after step 2?

A Replica set active

B Configuration object created

C No replica set configured

D Members syncing

💡 Hint

Check the 'Configuration State' column in row for step 2 in execution_table

At which step do members start syncing data?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for when syncing begins

If you forget to assign unique _id to members, what will happen?

A Configuration will fail or cause errors

B Replica set initiates normally

C Members will sync but slowly

D Primary member will be elected twice

💡 Hint

Refer to key_moments about unique _id importance

Concept Snapshot

MongoDB replica set configuration:
- Use rs.initiate() with config object
- Config includes _id (set name) and members array
- Each member needs unique _id and host
- After applying config, members sync data
- Replica set runs with primary and secondaries

Full Transcript

This visual execution shows how to configure a MongoDB replica set. First, you call rs.initiate() with a configuration object that defines the replica set name (_id) and its members with unique _id and host addresses. The configuration is applied, initiating the replica set. Members then start syncing data to replicate changes. The replica set becomes active with primary and secondary members working together. Key points include the need for unique member _id values and that members automatically sync after configuration. The execution table traces each step from initiation to running state, and the variable tracker shows how configuration variables change. This helps beginners see the process clearly and understand the importance of each step.

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