You have configured GTID-based asynchronous replication with one master and one slave. A user accidentally updated some data on the slave. To fix this, you stopped replication and successfully…

Question

Exhibit

Options

• ARESET MASTER;
• BSET GLOBAL gtid_purged=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2312,bbbbbbbb-bbbb-
• CRESET SLAVE;
• DRESET MASTER;
• ERESET SLAVE;

• A
  3% (1)
• B
  3% (1)
• C
  11% (4)
• D
  63% (22)
• E
  20% (7)

Explanation

Option D is correct because fixing GTID corruption on a slave requires a specific sequence: RESET MASTER (run on the slave) clears gtid_executed - the slave's record of all executed transactions - making it empty so that gtid_purged can be set. Then SET GLOBAL gtid_purged injects the correct GTID set from the master, telling the slave "pretend these transactions were already applied." Finally, START SLAVE resumes clean replication from the right point.

Why the distractors fail:

• A (RESET MASTER alone): Incomplete - clears the GTID state but never restores the correct gtid_purged value or restarts replication.
• B (SET GLOBAL gtid_purged alone): Will throw an error; MySQL only allows setting gtid_purged when gtid_executed is empty, which requires RESET MASTER first.
• C / E (RESET SLAVE): Resets replication connection metadata and relay logs, but does not touch gtid_executed - the rogue GTIDs remain and will still cause problems during failover.

Memory tip: It feels backwards, but you run RESET MASTER on the slave to fix slave GTID problems - because gtid_executed lives in the binary log, which is a "master" concept. Think of it as: "Reset the slave's inner master to clear the slate, then paint the correct GTIDs with gtid_purged."

No community discussion yet for this question.