Examine the modified output: Seconds_Behind_ Master value is steadily growing. What are two possible causes? (Choose two.)

Question

Options

• AThe master is most probably too busy to transmit data and the slave needs to wait for more data.
• BOne or more large tables do not have primary keys.
• CThis value shows only I/O latency and is not indicative of the size of the transaction queue.
• DThe master is producing a large volume of events in parallel but the slave is processing them
• EThe parallel slave threads are experiencing lock contention.

• A
  14% (5)
• B
  5% (2)
• C
  57% (21)
• E
  24% (9)

Explanation

Seconds_Behind_Master reflects a timestamp delta between the slave SQL thread's last applied event and the master's current time - D directly explains why this grows: when the master writes transactions in parallel but the slave replays them serially (or with insufficient parallelism), the slave's throughput cannot match the master's, so the lag accumulates continuously. C is correct because this metric is derived from event timestamps captured by the I/O thread - it does not directly measure the depth of the relay log queue, so a growing value can mislead you about where the bottleneck actually is (I/O reception vs. SQL execution backlog).

A is wrong because master transmission speed affects the I/O thread, not the SQL thread timestamp delta that Seconds_Behind_Master tracks - I/O lag and SQL lag are separate. B is a real performance concern (missing PKs cause full table scans on row-based replication) but is not a direct cause of steadily growing Seconds_Behind_Master in this scenario. E (parallel slave lock contention) is also a legitimate replication lag cause in MTS setups, which is why it's a tempting distractor - the exam is steering you toward the more fundamental architectural mismatch in D and the metric's measurement limitation in C.

Memory tip: Think "WHAT does the value measure, and WHY can't the slave keep up?" - C addresses the measurement limitation (timestamp-based, not queue-depth), D addresses the throughput mismatch (parallel writes in, serial processing out). If you anchor on those two angles, the distractors fall away.

No community discussion yet for this question.