Replication lag monitoring in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to check the replication offset on a Redis slave.

Redis

redis-cli info replication | grep [1]

Drag options to blanks, or click blank then click option'

Aconnected_slaves

Bmaster_repl_offset

Cslave_repl_offset

Drole

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'master_repl_offset' which shows master's offset, not slave's.

Using 'connected_slaves' which shows count, not offset.

The slave_repl_offset shows the replication offset on the slave, which helps monitor replication lag.

2fill in blank

medium

Complete the command to check the replication lag in seconds using Redis latency info.

Redis

redis-cli latency latest | grep [1]

Drag options to blanks, or click blank then click option'

Areplication-delay

Bcommand-stats

Cslowlog

Dlatency

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'command-stats' which shows command statistics, not replication lag.

Using 'slowlog' which shows slow commands, unrelated to replication lag.

The replication-delay latency event shows the delay in seconds between master and slave.

3fill in blank

hard

Fix the error in the command to monitor replication lag by comparing master and slave offsets.

Redis

master_offset=$(redis-cli info replication | grep [1] | cut -d':' -f2)
slave_offset=$(redis-cli info replication | grep slave_repl_offset | cut -d':' -f2)
lag=$((master_offset - slave_offset))
echo $lag

Drag options to blanks, or click blank then click option'

Amaster_repl_offset

Bslave_repl_offset

Cconnected_slaves

Drole

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'slave_repl_offset' for master offset causes incorrect lag calculation.

Using 'connected_slaves' which is unrelated to offsets.

The master offset must be fetched using master_repl_offset to calculate lag correctly.

4fill in blank

hard

Fill both blanks to create a Redis command that shows replication lag in bytes and seconds.

Redis

redis-cli info replication | grep [1]
redis-cli latency latest | grep [2]

Drag options to blanks, or click blank then click option'

Amaster_repl_offset

Breplication-delay

Cslave_repl_offset

Dcommand-stats

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'slave_repl_offset' instead of 'master_repl_offset' for byte lag.

Using 'command-stats' which is unrelated to replication lag.

The master_repl_offset shows lag in bytes, and replication-delay shows lag in seconds.

5fill in blank

hard

Fill all three blanks to create a script snippet that calculates replication lag in bytes and prints a warning if lag exceeds threshold.

Redis

master_offset=$(redis-cli info replication | grep [1] | cut -d':' -f2)
slave_offset=$(redis-cli info replication | grep [2] | cut -d':' -f2)
lag=$((master_offset - slave_offset))
if [ $lag -gt [3] ]; then
  echo "Warning: Replication lag is high: $lag bytes"
fi

Drag options to blanks, or click blank then click option'

Amaster_repl_offset

Bslave_repl_offset

C1000

Dconnected_slaves

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up master and slave offset keys.

Using a non-numeric value for the threshold.

The script compares master_repl_offset and slave_repl_offset to find lag in bytes and warns if lag is greater than 1000 bytes.

Practice

1. What does the master_last_io_seconds_ago field in INFO replication indicate in Redis?

easy

A. The number of seconds since the master last communicated with the replica

B. The total number of connected replicas

C. The current memory usage of the master

D. The replication backlog size in bytes

Solution

1. Step 1: Understand the INFO replication output

   This command shows replication details including communication status between master and replicas.

2. Step 2: Interpret master_last_io_seconds_ago

   This field tells how many seconds ago the master last sent data to the replica, indicating replication lag.

3. Final Answer:

   The number of seconds since the master last communicated with the replica -> Option A

4. Quick Check:

   Replication lag = master_last_io_seconds_ago [OK]

Hint: Lag time is how long since last master-replica communication [OK]

Common Mistakes:

• Confusing lag with number of replicas
• Mixing memory usage with replication info
• Thinking backlog size shows lag

2. Which Redis command correctly shows replication lag details?

easy

A. SHOW replication

B. INFO replication

C. MONITOR replication

D. REPLICA STATUS

Solution

1. Step 1: Recall Redis commands for replication info

   The INFO command with the replication section shows replication status and lag.

2. Step 2: Verify command correctness

   MONITOR shows all commands, SHOW and REPLICA STATUS are invalid commands.

3. Final Answer:

   INFO replication -> Option B

4. Quick Check:

   Correct command = INFO replication [OK]

Hint: Use INFO replication to check lag, not monitor or show [OK]

Common Mistakes:

• Using MONITOR instead of INFO
• Trying non-existent commands
• Confusing SHOW with INFO

3. Given this INFO replication snippet:

master_link_status:up
master_last_io_seconds_ago:5

What does the master_last_io_seconds_ago value tell you?

medium

A. The replica is 5 seconds behind the master

B. The master has been down for 5 seconds

C. The master last sent data 5 seconds ago

D. There are 5 replicas connected

Solution

1. Step 1: Analyze master_link_status and master_last_io_seconds_ago

   The status 'up' means the master and replica are connected. The number 5 means 5 seconds since last data sent.

2. Step 2: Interpret the lag meaning

   The value shows how many seconds ago the master last communicated, not the exact lag or downtime.

3. Final Answer:

   The master last sent data 5 seconds ago -> Option C

4. Quick Check:

   master_last_io_seconds_ago = last data sent seconds [OK]

Hint: Lag means last data sent time, not downtime or replica count [OK]

Common Mistakes:

• Confusing lag with downtime
• Assuming number means replicas count
• Thinking it shows replica delay exactly

4. You run INFO replication and see master_link_status:down and master_last_io_seconds_ago:1000. What is the best first step to fix replication lag?

medium

A. Restart the Redis master server immediately

B. Flush all data on the replica

C. Increase the replication backlog size

D. Check network connectivity between master and replica

Solution

1. Step 1: Understand the meaning of master_link_status:down

   This means the replica lost connection to the master, causing lag.

2. Step 2: Identify the cause and fix

   Network issues are the common cause; checking connectivity is the first step before restarting or changing configs.

3. Final Answer:

   Check network connectivity between master and replica -> Option D

4. Quick Check:

   Link down means network check first [OK]

Hint: Link down? Check network before restarting or flushing [OK]

Common Mistakes:

• Restarting master without checking network
• Changing backlog size without cause
• Flushing replica data unnecessarily

5. You want to alert if replication lag exceeds 10 seconds. Which approach using INFO replication is best?

hard

A. Parse master_last_io_seconds_ago and trigger alert if > 10

B. Check connected_slaves count and alert if less than 1

C. Monitor master_link_status only for 'down' status

D. Use INFO memory to check memory usage spikes

Solution

1. Step 1: Identify the lag metric

   master_last_io_seconds_ago directly shows how many seconds since last master-replica communication, ideal for lag monitoring.

2. Step 2: Set alert condition

   Trigger alert when this value exceeds 10 seconds to catch lag early.

3. Final Answer:

   Parse master_last_io_seconds_ago and trigger alert if > 10 -> Option A

4. Quick Check:

   Lag alert = master_last_io_seconds_ago > threshold [OK]

Hint: Alert on master_last_io_seconds_ago > threshold seconds [OK]

Common Mistakes:

• Using connected_slaves count for lag
• Only watching link status without lag value
• Checking memory instead of replication lag