Master-replica architecture in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of the command INFO replication on a Redis replica?

You run INFO replication on a Redis replica node. What key information will you see in the output?

Redis

INFO replication

A role:replica, master_host:<ip>, master_link_status:up

B role:master, connected_slaves:0

C role:client, connected_clients:10

D role:sentinel, monitored_masters:1

💡 Hint

Think about what role a replica plays and what info it reports about its master.

A Redis replica reports its role as 'replica' (or 'slave' in older versions), shows the master's IP, and the link status to the master. Masters report connected slaves, sentinels report monitored masters, and clients report connected clients.

🧠 Conceptual

intermediate

Why does a Redis replica not accept write commands by default?

In a master-replica setup, why are write commands disabled on replicas by default?

A To prevent data inconsistency by ensuring writes happen only on the master

B Because replicas have no memory to store data

C To reduce network traffic between nodes

D Because replicas only store metadata, not actual data

💡 Hint

Consider the role of master and replica in data consistency.

Writes are allowed only on the master to keep data consistent. Replicas replicate data from the master and do not accept writes to avoid conflicts.

📝 Syntax

advanced

Which Redis command correctly promotes a replica to master?

You want to promote a Redis replica to become a master. Which command will do this correctly?

A PROMOTE MASTER

B SLAVEOF NO ONE

C REPLICAOF NO ONE

D MASTER PROMOTE

💡 Hint

The command changed name in recent Redis versions.

The command to promote a replica to master is 'REPLICAOF NO ONE' in modern Redis versions. 'SLAVEOF' is deprecated but still works in older versions. The other commands do not exist.

❓ optimization

advanced

How can you reduce replication lag in a Redis master-replica setup?

Which approach helps reduce replication lag between master and replica in Redis?

A Use synchronous replication mode

B Increase the number of replicas to distribute load

C Disable AOF persistence on the master

D Enable diskless replication to send data directly over the network

💡 Hint

Think about how data is transferred from master to replica.

Diskless replication sends data directly over the network without writing to disk first, reducing lag. Increasing replicas doesn't reduce lag per replica. Disabling AOF affects persistence, not replication lag. Redis replication is asynchronous; synchronous mode is not supported.

🔧 Debug

expert

Why does a Redis replica show master_link_status:down after network recovery?

After a network outage, your Redis replica shows master_link_status:down even though the network is restored. What is the most likely cause?

A The master has crashed and is not accepting connections

B The replica's replication backlog is lost and needs a full resync

C The replica is still configured as a master

D The replica's IP address changed and is not updated

💡 Hint

Consider what happens to replication state after network failures.

If the replication backlog is lost during outage, the replica cannot catch up incrementally and must perform a full resync, causing the link to stay down until resync completes. Master crash or IP change would cause different symptoms. Replica configured as master would not show master link status.

Practice

1. What is the main purpose of the master-replica architecture in Redis?

easy

A. To copy data from one main server to others for safety and speed

B. To delete data from all servers simultaneously

C. To run multiple unrelated databases on one server

D. To encrypt data on the master server only

Solution

1. Step 1: Understand the role of master and replicas

   The master server holds the original data, and replicas copy this data to keep backups and improve read speed.

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

   This setup is mainly for safety (backup) and speed (load distribution).

3. Final Answer:

   To copy data from one main server to others for safety and speed -> Option A

4. Quick Check:

   Master-replica = data copy for safety and speed [OK]

Hint: Master copies data to replicas for safety and speed [OK]

Common Mistakes:

• Thinking replicas delete data
• Confusing master-replica with encryption
• Believing replicas run unrelated databases

2. Which Redis command correctly sets a server as a replica of another?

easy

A. REPLICAOF <port>

B. SETREPLICA <port>

C. SLAVEOF <port>

D. COPYTO <port>

Solution

1. Step 1: Recall the Redis command for setting a replica

   The correct command is SLAVEOF followed by the master's IP and port.

2. Step 2: Check the options for exact command syntax

   Only SLAVEOF <port> uses the correct command SLAVEOF.

3. Final Answer:

   SLAVEOF <master-ip> <port> -> Option C

4. Quick Check:

   Set replica with SLAVEOF command [OK]

Hint: Use SLAVEOF to set replica, not REPLICAOF or others [OK]

Common Mistakes:

• Using REPLICAOF instead of SLAVEOF
• Trying non-existent commands like SETREPLICA
• Confusing COPYTO with replication commands

3. Given this Redis command sequence on a replica server:

SLAVEOF 192.168.1.10 6379
GET user:100

What will happen if the master at 192.168.1.10 is down?

medium

A. The replica will return an error because it can't reach the master

B. The replica will return the last synced value for user:100

C. The replica will become master automatically

D. The replica will delete the user:100 key

Solution

1. Step 1: Understand replica behavior when master is down

   The replica keeps the last synced data even if the master is offline.

2. Step 2: Predict the GET command result on replica

   GET will return the last known value for the key from the replica's local data.

3. Final Answer:

   The replica will return the last synced value for user:100 -> Option B

4. Quick Check:

   Replica serves last synced data if master is down [OK]

Hint: Replica serves cached data if master is unreachable [OK]

Common Mistakes:

• Assuming replica errors out when master is down
• Thinking replica auto-promotes to master
• Believing replica deletes keys on master failure

4. You run SLAVEOF NO ONE on a Redis replica server but it still behaves like a replica. What is the likely problem?

medium

A. The server is still connected to the master and did not switch roles

B. The server needs a restart to apply the change

C. The command was typed incorrectly; it should be SLAVE OF NO ONE

D. SLAVEOF NO ONE only works on master servers

Solution

1. Step 1: Understand what SLAVEOF NO ONE does

   This command tells the server to stop replicating and become a master.

2. Step 2: Identify why the server still acts as replica

   If the server is still connected or replication not stopped properly, it remains a replica.

3. Final Answer:

   The server is still connected to the master and did not switch roles -> Option A

4. Quick Check:

   Server must disconnect from master to become master [OK]

Hint: Ensure replica disconnects from master to become master [OK]

Common Mistakes:

• Typing SLAVE OF instead of SLAVEOF
• Thinking restart is always needed
• Believing SLAVEOF NO ONE only works on masters

5. You want to ensure your Redis setup continues working if the master fails. Which approach best uses master-replica architecture?

hard

A. Use only one replica and manually copy data to it daily

B. Disable replication and rely on backups only

C. Run multiple masters without replicas to balance load

D. Set multiple replicas and configure automatic failover to promote a replica to master

Solution

1. Step 1: Identify the goal of continuous operation

   To keep Redis working if master fails, replicas must be ready to take over automatically.

2. Step 2: Evaluate options for failover and replication

   Set multiple replicas and configure automatic failover to promote a replica to master uses multiple replicas and automatic failover, which is the best practice.

3. Final Answer:

   Set multiple replicas and configure automatic failover to promote a replica to master -> Option D

4. Quick Check:

   Multiple replicas + auto failover = high availability [OK]

Hint: Use multiple replicas with auto failover for master failure [OK]

Common Mistakes:

• Relying on manual data copy only
• Running multiple masters without replicas
• Disabling replication and trusting backups alone