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…
Question
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)- B3% (1)
- C3% (1)
- D94% (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 affectSeconds_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, notSQL_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
Community Discussion
No community discussion yet for this question.