nerdexam
Oracle

1Z0-888 · Question #59

This output is from a SHOW SLAVE STATUS: `` mysql> SHOW SLAVE STATUS\G ************************ 1. row ************************ Slave_IO_state: Waiting for master to send event ... Slave_IO_Running…

The correct answer is D. The slave was configured for delayed replication with a delay of six minutes. D is correct because SQL_Delay reflects a deliberately configured replication delay, set via CHANGE MASTER TO MASTER_DELAY = 360. This feature intentionally holds the SQL thread back from applying relay log events, creating a lagged replica - useful for recovering from…

Replication

Question

This output is from a SHOW SLAVE STATUS:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
 Slave_IO_state: Waiting for master to send event
 ...
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 ...
 SQL_Delay: 360
 SQL_Remaining_Delay: NULL
Slave_SQL_running_state: Slave has read all relay log; waiting for the slave I/O
 thread to update it
What would cause the SQL_Delay value to have a value of 360?

Options

  • AThe master has performed a large transaction, which will take 360 seconds to complete on the slave.
  • BThe network latency between the master and the slave is 360 milliseconds.
  • CThe slave will need an estimated 360 seconds to update the remaining contents from the relay log.
  • DThe slave was configured for delayed replication with a delay of six minutes.

How the community answered

(36 responses)
  • B
    3% (1)
  • C
    3% (1)
  • D
    94% (34)

Explanation

D is correct because SQL_Delay reflects a deliberately configured replication delay, set via CHANGE MASTER TO MASTER_DELAY = 360. This feature intentionally holds the SQL thread back from applying relay log events, creating a lagged replica - useful for recovering from accidental data changes. The value 360 means the slave applies events 360 seconds (6 minutes) after the master committed them, confirmed by SQL_Remaining_Delay: NULL, which shows no delay is currently being waited on (all caught up to the lag boundary).

Why the distractors fail:

  • A is wrong - large transaction duration is not captured in SQL_Delay; it would affect Seconds_Behind_Master, not this field.
  • B is wrong - network latency is measured in milliseconds and has no bearing on SQL_Delay, which is a configuration value in seconds.
  • C is wrong - remaining relay log processing time would appear in SQL_Remaining_Delay, not SQL_Delay; and the status shows the slave has already read all relay log.

Memory tip: Think of SQL_Delay as a "configured pause" - it's always a human-set number (via CHANGE MASTER TO), not a dynamic measurement. If you see a suspiciously round number like 360, think "someone set this on purpose."

Topics

#delayed replication#SQL_Delay parameter#SHOW SLAVE STATUS#replication configuration

Community Discussion

No community discussion yet for this question.

Full 1Z0-888 Practice