Group Replication uses global transaction identifiers to track executed transactions and are fundamental in avoiding transaction conflict. Which additional three steps help in avoiding conflicts in…

Question

Options

• ASet isolation level to be SERIALIZABLE.
• BUse the binary log row format.
• CSet isolation level to be READ COMMITTED.
• DConfigure IPv6 network for hosts.
• EGuarantee a secondary index on every table.
• FGuarantee a primary key on every table.
• GSet multiple slave parallel worker threads.

• A
  65% (24)
• C
  3% (1)
• D
  8% (3)
• E
  5% (2)
• G
  19% (7)

Explanation

MySQL Group Replication's conflict detection relies on three core requirements working alongside GTIDs. SERIALIZABLE isolation (A) ensures that each transaction acquires locks covering its entire read set before committing, preventing two transactions on different nodes from making conflicting changes to the same rows simultaneously. Row-based binary logging (B) is mandatory because Group Replication must track exactly which rows are modified-statement-based logging is ambiguous and cannot reliably identify conflicts across nodes. A primary key on every table (F) is required because the conflict detection algorithm uses primary keys to identify whether two concurrent write-sets affect the same row; without a PK, the engine has no reliable row identifier to compare.

The distractors fail for these reasons: (C) READ COMMITTED is weaker than SERIALIZABLE and allows non-repeatable reads, increasing the chance of write conflicts rather than preventing them. (D) IPv6 configuration is a network concern unrelated to transaction ordering or conflict detection. (E) Secondary indexes help with query performance but are not used by the conflict detection mechanism-only primary keys matter for row identity. (G) Parallel worker threads affect applier throughput on secondaries but have no bearing on whether conflicts occur.

Memory tip: Think "Row, Serial, Primary" - the three pillars that let Group Replication unambiguously identify, order, and compare every transaction's write-set across all nodes.

No community discussion yet for this question.