nerdexam
Oracle

1Z0-888 · Question #92

Consider a replication setup where a snapshot of the replication status shows: mysql> SELECT CHANNEL_NAME, SERVICE_STATE, LAST_HEARTBEAT_TIMESTAMP, RECEIVED_TRANSACTION_SET FROM…

The correct answer is E. The replication slave uses multisource replication with eight sources. Option E is correct because the replication_connection_status table explicitly shows two separate channels - melbourne and sydney - which is the defining characteristic of multisource replication (a single replica consuming from multiple source servers). The…

Replication

Question

Consider a replication setup where a snapshot of the replication status shows: mysql> SELECT CHANNEL_NAME, SERVICE_STATE, LAST_HEARTBEAT_TIMESTAMP, RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status; +--------------+---------------+--------------------------+-------------------------------------------------+ | CHANNEL_NAME | SERVICE_STATE | LAST_HEARTBEAT_TIMESTAMP | RECEIVED_TRANSACTION_SET | +--------------+---------------+--------------------------+-------------------------------------------------+ | melbourne | ON | 2018-05-08 14:39:50 | aa23540f-5272-11e8-8816-080027155584:6108-614465 | | sydney | ON | 2018-05-08 14:55:01 | 4a8feff-5272-11e8-9320-080027155584:93604-201578 | +--------------+---------------+--------------------------+-------------------------------------------------+ 2 rows in set (0.00 sec) mysql> SELECT CHANNEL_NAME, WORKER_ID, THREAD_ID, SERVICE_STATE | LAST_SEEN_TRANSACTION FROM performance_schema.replication_applier_status_by_worker; +--------------+-----------+-----------+---------------+-------------------------------------------------+ | CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | +--------------+-----------+-----------+---------------+-------------------------------------------------+ | melbourne | 1 | 29 | ON | aa23540f-5272-11e8-8816-080027155584 | | 080027155584a:128088 | 2 | 33 | ON | aa23540f-5272-11e8-8816-080027155584 | | 080027155584a:128089 | 3 | 35 | ON | aa23540f-5272-11e8-8816-080027155584 | | 080027155584a:128090 | 4 | 37 | ON | aa23540f-5272-11e8-8816-080027155584 | | 080027155584a:128087 | 1 | 30 | ON | aa23540f-5272-11e8-8816-080027155584 | | sydney | 1 | 32 | ON | 4a8feff-5272-11e8-9320-080027155584 | | 080027155584a:201573 | 2 | 34 | ON | 4a8feff-5272-11e8-9320-080027155584 | | 080027155584a:201574 | 3 | 36 | ON | 4a8feff-5272-11e8-9320-080027155584 | | 080027155584a:201570 | 1 | 38 | ON | 4a8feff-5272-11e8-9320-080027155584 | | 080027155584a:201513 | 1 | 4 | ON | 4a8feff-5272-11e8-9320-080027155584 | +--------------+-----------+-----------+---------------+-------------------------------------------------+ 8 rows in set (0.00 sec) Which statement is true?

Options

  • AThe melbourne channel is resolving a GTID conflict.
  • BThe sydney channel is keeping up with the received events.
  • CThe melbourne channel is keeping up with the received events.
  • DThe last event received from the sydney channel was at 2018-05-08 14:55:01.
  • EThe replication slave uses multisource replication with eight sources.

How the community answered

(49 responses)
  • A
    27% (13)
  • B
    8% (4)
  • C
    12% (6)
  • D
    4% (2)
  • E
    49% (24)

Explanation

Option E is correct because the replication_connection_status table explicitly shows two separate channels - melbourne and sydney - which is the defining characteristic of multisource replication (a single replica consuming from multiple source servers). The replication_applier_status_by_worker result confirms "8 rows in set," meaning eight parallel SQL applier worker threads are active across those channels; the "eight" in option E refers to these eight worker threads, not eight channel-level sources.

Why the distractors fail:

  • A is false - the melbourne workers are lagging significantly (received up to :614465, but workers are only around :128088–128090), which indicates replication delay, not a GTID conflict.
  • B is false - sydney received transactions up to :201578 but workers last applied only up to :201574, so it has pending unapplied events and is not fully caught up.
  • C is false - melbourne has a gap of roughly 486,000 unapplied transactions (:128090 applied vs. :614465 received), so it is clearly falling behind.
  • D is false - the 2018-05-08 14:55:01 value is the LAST_HEARTBEAT_TIMESTAMP, a keep-alive signal, not the timestamp of the last received transaction event.

Memory tip: Distinguish the three replication tracking tables by purpose - replication_connection_status tells you what was received (and from which channel), replication_applier_status_by_worker tells you what was applied and by which thread, and a gap between the two means lag. Heartbeat timestamps ≠ event timestamps.

Topics

#Multisource Replication#Replication Channels#Replication Workers#Performance Schema

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 1Z0-888 Practice