Understanding MySQL Group Replication: Architecture and Conflict Resolution Mechanisms

Database replication has evolved significantly to address data consistency and availability challenges. Early implementations relied on asynchronous replication, where the primary node commits transactions without waiting for acknowledgment from replicas. While fast, this approach risks data loss or divergence if a replica fails to apply changes or encounters disk failures.

Semi-synchronous replication was introduced to mitigate this gap. It requires at least one replica to acknowledge receipt of the binary logs before the primary confirms a commit. However, application-level execution on replicas remains asynchronous, and network partitions can still block primary commits indefinitely or cause cascading timeouts.

MySQL Group Replication (MGR) represents a paradigm shift by implementing a distributed plugin that enforces strict consensus across all participating instances. Leveraging a variant of the Paxos algorithm alongside write-set certification, MGR guarantees linearizability within a cluster. Each member maintains a complete data copy, communicating through a dedicated protocol layer that handles membership management, order delivery, and conflict resolution.

Core Capabilities and Operational Constraints

MGR delivers several architectural advantages designed for modern high-availability environments:

• Strong Consistency: Transactions are applied in the exact same order across all nodes, eliminating replication lag divergence.
• Fault Tolerance: The system tolerates up to (N-1)/2 simultaneous failures. Automatic conflict resolution uses a first-come-first-served strategy, and built-in anti-partition safeguards prevent split-brain scenarios.
• Dynamic Scalability: Adding or removing members triggers automatic state synchronization via incremental cloning, maintaining cluster equilibrium without manual intervention.
• Flexible Topologies: Supports Single-Primary mode (primary handles all DMLs, others act as read replicas) and Multi-Primary mode (all members accept writes).

Despite its robustness, deployment requires adherence to specific constraints:

• Only InnoDB storage engines are supported. Every table must define a primary key to enable write-set tracking.
• Global Transaction IDs (GTID) must be enabled, and binary logging format must be set to ROW.
• Transactional metadata repositories should use table-based storage rather than file-based to ensure recovery resilience.
• Cluster size is capped at nine members to balance communication overhead and consensus latency.
• External foreign key enforcement and explicit savepoints are not processed globally, limiting cross-node constraint validation.

Transaction Lifecycle and Consensus Flow

When a client issues a modification request, the transaction begins local on the initiating server. Upon reaching the commit phase, the transaction enters the Group Replication module. Instead of immediately writing to disk, the instance packages transactional metadata and broadcasts it to the group.

A consensus engine evaluates the proposal using majority voting. Once a quorum of (N/2 + 1) members acknowledges receipt and validity, the message transitions to the certification subsystem. Each node independently validates the incoming payload against its local state. If validation succeeds, the transaction commits locally; otherwise, it is rolled back. Remote members replicate the accepted changes via standard redo logs and apply them sequentially.

Internal Data Structures: Message Payload and Certification State

Efficient conflict detection relies on two critical internal constructs:

Message Payload Definition

The broadcast unit encapsulates three core segments:

struct BroadcastMessage {
    AffectedRowsHash write_checksum;  // Hash of modified table+pk combinations
    GTIDSet executed_view;            // Snapshot of previously committed GIDs
    LogEventBundle payload_container; // Raw ROW-format binlog events
}

The write_checksum is generated by hashing the schema name, table identifier, and primary key values of every affected row. This compact representation allows rapid intersection checks during validation.

Certification State Table

Each node maintains an in-memory mapping registry used exclusively for concurrency control. The structure resembles a composite dictionary where keys represent extracted primary key identifiers, and values store associated GTIDSet ranges. For example, when a transaction modifies rows with IDs [10, 25] under view server_id:104, the registry records:

Key: "10_25"  => Value: { server_id:104 }

This lookup table enables O(1) collision detection without scanning historical binlogs.

Write-Set Validation and Conflict Arbitration

The certification engine operates on a strict sequencing rule: incoming transactions must exhibit monotonically increasing global sequence numbers relative to existing entries. Consider three parallel operations arriving simultaneously:

1. If multiple statements target identical row identifiers, they undergo strict chronological verification based on their assigned sequence tokens.
2. Statements affecting disjoint row sets bypass serialization and execute concurrently.
3. Conflicts over shared resources trigger rejection for the lower-priority participant.

Implementation logic proceeds as follows:

• Transaction T_A targets row ID 42 with sequence token GID:105. The registry holds token GID:102 for this key. Since 105 > 102, validation passes and the registry updates to GID:106.
• Concurrently, T_B also targets ID 42 but carreis sequence token GID:100. Comparing against the updated registry entry (GID:105), validation fails due to temporal inversion. T_B triggers an automatic rollback to preserve integrity.
• Transaction T_C modifies a distinct resource (ID 88). With no prior occupancy recorded, immediate approval occurs.

To prevent unbounded memory growth from accumulating certification states, a dedicated background daemon periodically purges validated sequences once downstream replication confirms successful application. This garbage collection loop ensures long-running clusters maintain predictable memory footprints.